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_hosts
pliku.
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?
Odpowiedzi:
pobierz klucz rsa swojego serwera, gdzie
server_ip
jest adres IP twojego serwera, taki jak192.168.2.1
:Przykładowa odpowiedź:
a na kliencie skopiuj całą linię odpowiedzi
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
i dodaj ten klucz na dole~/.ssh/known_hosts
pliku:źródło
ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip
- ale jedynym powodem do znalezieniarsa1
idsa
kluczy jest zidentyfikowanie serwerów, które wymagają aktualizacji / rekonfiguracjiUsuń wpis ze znanych hostów za pomocą:
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ódło
Bardzo prosty sposób to:
Następnie edytuj znane_hosty, aby wyczyścić oryginalny klucz, a następnie ssh do hosta, używając:
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];
Istnieje nawet opcja HostKeyAlias jak w
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
źródło
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:
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:
Każda odmiana (niekanonizowanego) adresu IP otrzymuje własny wpis w znanych_hostach.
źródło
CheckHostIP no
w~/.ssh/config
aby móc nadal korzystać z luki. Możesz nawet zdefiniować tam swoje aliasy, abyś nie musiał się bawić/etc/hosts
i definiowaćCheckHostIP no
tylko dla tych 3 nazw hostów.Jeśli zarówno klient, jak i serwer mają OpenSSH 6.8 lub nowszy, możesz użyć tej
UpdateHostKeys yes
opcji w swoimssh_config
lub~/.ssh/config
. Na przykład: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 twoimknown_hosts
.źródło
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_hosts
pliku, ale musisz to zrobić ręcznie.Innym rozwiązaniem może być użycie
StrictHostKeyChecking=no
opcji dla tego konkretnego hosta:który możesz umieścić w swoim aliasie
~/.profile
lub coś podobnego.źródło
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
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!
źródło
known_hosts
pliku za każdym razem spowoduje zanegowanie większości zabezpieczeń zapewnianych w inny sposób przez ssh.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
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.
źródło
Miałem ten sam problem.
Wszystko, co zrobiłem, to
sudo nano /home/user/.ssh/ host_allow
usunąłem klucz.Kiedy wróciłem do serwera, dodałem nowy klucz.
źródło
Użyj polecenia sed, aby usunąć linię obrażającą
Usuń wiersz 86, jak wspomniano w znanych hostach.
Następnym razem podczas uzyskiwania dostępu za pomocą ssh, system automatycznie doda nowy klucz.
nowsze wersje ssh
posługiwać się:
Spowoduje to usunięcie wpisu nazwy hosta i wykonanie kopii zapasowej starej
.known_host
jakoknown_hosts.old
źródło