Próbując ssh do komputera, który kontroluję, otrzymuję znajomy komunikat:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

Naprawdę zmieniłem klucz. Przeczytałem kilkadziesiąt postów mówiących, że sposobem na rozwiązanie tego problemu jest usunięcie starego klucza z known_hostspliku.

Ale chciałbym, aby ssh zaakceptował zarówno stary klucz, jak i nowy klucz. Język komunikatu o błędzie („ Add correct host key”) sugeruje, że powinien istnieć sposób na dodanie poprawnego klucza hosta bez usuwania starego.

Nie udało mi się dowiedzieć, jak dodać nowy klucz hosta bez usunięcia starego.

Czy to możliwe, czy też komunikat o błędzie jest po prostu bardzo mylący?

1. pobierz klucz rsa swojego serwera, gdzie server_ipjest adres IP twojego serwera, taki jak 192.168.2.1:

   $ ssh-keyscan -t rsa server_ip
   

   Przykładowa odpowiedź:

   # server_ip SSH-2.0-OpenSSH_4.3
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
   

2. a na kliencie skopiuj całą linię odpowiedzi server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...i dodaj ten klucz na dole ~/.ssh/known_hostspliku:

   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
   

Usuń wpis ze znanych hostów za pomocą:

ssh-keygen -R *ip_address_or_hostname*

Spowoduje to usunięcie problematycznego adresu IP lub nazwy hosta z pliku znane_hosty i ponowne nawiązanie połączenia.

Ze stron podręcznika:

-R hostname
Usuwa wszystkie klucze należące do nazwy hosta z pliku znane_hosty. Ta opcja jest przydatna do usuwania mieszanych hostów (patrz opcja -H powyżej).

Bardzo prosty sposób to:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Następnie edytuj znane_hosty, aby wyczyścić oryginalny klucz, a następnie ssh do hosta, używając:

ssh name@computer

Automatycznie doda nowy klucz; następnie porównaj dwa pliki. Program taki jak meld to dobry sposób na porównanie dwóch plików. Następnie scal pliki, aby znane_hosty zawierały oba klucze

Mój „powód” utrzymywania dwóch kluczy polega na tym, że system docelowy jest uruchamiany wielopunktowo, chociaż śmiem twierdzić, że istnieje sposób synchronizacji kluczy między instalacjami, wydaje się, że dopuszczenie wielu kluczy jest prostsze.

EDYCJA 2015/06

Powinienem dodać, powracając do tego teraz, że zauważam jeszcze prostszy sposób [dopóki wpis jest możliwy do zidentyfikowania, zwykle z nazwy hosta / adresu IP całkiem oprócz komunikatu o błędzie odnoszącego się do jego konkretnej lokalizacji];

1. Edytuj znane_hosty, aby tymczasowo dodać # na początku „starego” wpisu do znanych_hostów
2. Połącz [ssh z hostem], zgódź się na monit o dodanie nowego klucza „automatycznie”
3. Następnie ponownie edytuj znane hosty, aby usunąć #

Istnieje nawet opcja HostKeyAlias ​​jak w

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

następnie, po tym, jak klient ssh doda nowy klucz pod aliasem, możesz albo edytować znane_hosty, aby zastąpić alias `` prawdziwą '' nazwą hosta / adresem IP, albo połączyć się z tym wcieleniem tego hosta za pomocą opcji aliasu

Mam ten sam problem z Raspberry Pi, który uruchamiam z kilkoma różnymi systemami (system deweloperski do kompilacji plików binarnych, projektu, xbmc itp.) I napotkałem ten sam problem. Używają DHCP w sieci lokalnej, a mój router zawsze używał tego samego adresu IP, ponieważ adres MAC był taki sam. Rozwiązałem go, używając różnych nazw domen w pliku hosts:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

Plik znane_hosty zapisuje odciski palców według nazwy hosta, więc nawet jeśli jest to ten sam adres IP, każda unikalna nazwa hosta otrzymuje inny wpis.

Mam dość dodawania nazw do plików hostów za każdym razem, gdy korzystam z nowego systemu, więc wymyśliłem jeszcze bardziej leniwy sposób, używając początkowych zer na adresach IP, takich jak:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Każda odmiana (niekanonizowanego) adresu IP otrzymuje własny wpis w znanych_hostach.

Jeśli zarówno klient, jak i serwer mają OpenSSH 6.8 lub nowszy, możesz użyć tej UpdateHostKeys yesopcji w swoim ssh_configlub ~/.ssh/config. Na przykład:

Host *
    UpdateHostKeys yes

To powoduje, że SSH przechowuje wszystkie klucze hosta, których potrzebuje serwer known_hosts, a gdy serwer zmienia lub usuwa jeden klucz hosta, klucz ten jest również zmieniany lub usuwany w twoim known_hosts.

Nie rozumiem, dlaczego chcesz pracować z dwoma kluczami, ale z pewnością możesz dodać więcej niż jeden prawidłowy klucz do ~/.ssh/known_hostspliku, ale musisz to zrobić ręcznie.

Innym rozwiązaniem może być użycie StrictHostKeyChecking=noopcji dla tego konkretnego hosta:

ssh -o StrictHostKeyChecking=no user@host

który możesz umieścić w swoim aliasie ~/.profilelub coś podobnego.

alias hc=ssh -o StrictHostKeyChecking=no user@host

Jeśli używasz tylko ssh w sieci lokalnej, to ...

Prostym rozwiązaniem jest wyczyszczenie starego pliku klucza i zastąpienie go pustym. Umożliwi to ponowne autoryzowanie wszystkich połączeń za pomocą nowych kluczy. Jeśli masz klucze ssh przechowywane dla witryn poza siecią lokalną, musisz upewnić się, że Twoje początkowe połączenie jest bezpieczne, tak jak podczas pierwszego połączenia z tym serwerem.

na przykład

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Następnie naciśnij spację, backspace cntl + x i 'y', aby zapisać nowy bufor (plik). Jest to zła praktyka, ale dobrze, pod warunkiem, że nie regularnie wysyłasz wiadomości poza lokalną sieć (np. Serwer uni lub work)

W bezpiecznej sieci lokalnej jest to bezpieczne, ponieważ po prostu nie można dostać się do człowieka w środku ataku.

Zawsze lepiej jest używać kodu, który rozumiesz!

Tak wiele odpowiedzi, ale tak wiele, które rezygnują z ochrony, całkowicie wyłączając ścisłe sprawdzanie hosta lub niszcząc niepowiązane informacje o hostie lub zmuszając użytkownika do interaktywnego akceptowania kluczy, być może w późniejszym czasie, gdy jest to nieoczekiwane.

Oto prosta technika, która pozwala ci pozostawić ścisłe sprawdzanie hosta, ale zaktualizuj klucz w kontrolowany sposób, gdy spodziewasz się zmiany:

• Usuń stary klucz i zaktualizuj jednym poleceniem

  ssh-keygen -R server.example.com && \
      ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
  

• Powtórz z adresami IP lub innymi nazwami hostów, jeśli ich używasz.

Zaletą tego podejścia jest to, że ponownie uruchamia serwer dokładnie raz. Większość wersji ssh-keygen wydaje się nie zwracać błędu, jeśli serwer, który próbujesz usunąć, nie istnieje w znanym pliku hosts, jeśli jest to dla ciebie problem, użyj dwóch poleceń po kolei.

Podejście to sprawdza również łączność i wysyła ładną wiadomość do dzienników w komendzie ssh (która loguje się, aktualizuje klucz hosta i wysyła zaktualizowany klucz hosta SSH , a następnie natychmiast kończy działanie.

Jeśli twoja wersja ssh-keygen zwraca niezerowy kod wyjścia, a wolisz sobie z tym poradzić bez błędu, niezależnie od wcześniejszego połączenia, po prostu użyj dwóch poleceń w kolejności, ignorując wszelkie błędy polecenia ssh-keygen.

Jeśli użyjesz tej techniki, nigdy nie musisz zmieniać komendy ssh ani wyłączać sprawdzania hosta, z wyjątkiem tej jednej komendy ssh. Możesz być pewien, że przyszłe sesje ssh będą działać bez konfliktu lub konieczności jawnego przyjęcia nowego klucza, o ile powyższe polecenie ssh działało bezbłędnie.

Miałem ten sam problem.

Wszystko, co zrobiłem, to sudo nano /home/user/.ssh/ host_allowusunąłem klucz.

Kiedy wróciłem do serwera, dodałem nowy klucz.

Użyj polecenia sed, aby usunąć linię obrażającą

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Usuń wiersz 86, jak wspomniano w znanych hostach.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

Następnym razem podczas uzyskiwania dostępu za pomocą ssh, system automatycznie doda nowy klucz.

nowsze wersje ssh

posługiwać się:

ssh-keygen -R <hostname|ip address>

Spowoduje to usunięcie wpisu nazwy hosta i wykonanie kopii zapasowej starej .known_hostjakoknown_hosts.old