Identyfikacja zdalnego hosta ssh uległa zmianie

618

Ponownie zainstalowałem serwer i otrzymuję te wiadomości:

[user@hostname ~]$ ssh root@pong
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.

Próbowałem różnych rozwiązań, które znalazłem w Internecie. Mój known_hostsplik (zwykle ~/.ssh/known_hostsjest) jest w /var/lib/sss/pubconf/known_hosts. Próbowałem go edytować, ale pozostaje w jednym stanie. Zainstalowałem klienta ipa i mam Fedorę 19. Jak rozwiązać to ostrzeżenie?

Wszystkie odpowiedzi, na które dotychczas udzielono odpowiedzi, działają tylko wtedy, gdy nie masz zainstalowanej Freeipa.

Prawidłowa odpowiedź na freeipa w komentarzach poniżej z adrin jest tutaj .

Filip Dobrovolný
źródło
1
właśnie dowiedziałem się, że ten problem może się również zdarzyć, jeśli masz konflikt adresów IP
nszukaj
1
Tu jest impas. Ten jest oznaczony jako duplikat, więc nikt nie może dodać odpowiedzi, a ten, do którego prowadzi, jest oznaczony jako temat, więc nie można również dodać odpowiedzi. Jeśli usuniesz znane_hosty, rozwiąże to również problem.
zar
1
Miałem ten sam problem. Ze względu na moje i innych, oto pytanie i moja odpowiedź na to: superuser.com/questions/1071204/…
adrin 29.04.16
3
Gdy ktoś chciał zweryfikować swój klucz, uznałem tę odpowiedź za przydatną. askubuntu.com/a/83499/620623
Declan McKenna
Jak wspomina sharrajesh: sprawdź swoje wpisy DNS (w FreeIPA dla mnie) i sprawdź, czy nie masz wielu wpisów A z adresami IP, które nie są dostępne z sieci.
th3penguinwhisperer

Odpowiedzi:

1070

Oto najprostsze rozwiązanie

ssh-keygen -R <host>

Na przykład,

ssh-keygen -R 192.168.3.10

Ze ssh-keygenstrony podręcznika :

  • -R hostnameUsuwa 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).
Kashif Nazar
źródło
Korzystam z systemu Windows i to rozwiązanie, a usunięcie klucza nie działa, co jeszcze mogę spróbować?
jaycode
5
W porządku, okazuje się, że w systemie Windows muszę do tego użyć terminala z git bash (lub dowolnego terminala MingW32). Zdradliwy.
jaycode
25
pamiętaj, że jeśli łączysz się przez określony port, być może będziesz musiał usunąć składnię podobną do tej ssh-keygen -R [127.0.0.1]:3022. Po prostu sprawdź plik .ssh / known_hosts pod kątem tego, co wyraźnie mówi.
Adam Johns
4
Gdy próbuję,
pojawia
3
Dlaczego pojawia się to ostrzeżenie?
Vilas Joshi
199

Posługiwać się

ssh-keygen -R [hostname]

Przykład z adresem IP / nazwą hosta to:

ssh-keygen -R 168.9.9.2

Spowoduje to zaktualizowanie obrażeń twojego hosta ze znanych_hostów. Możesz także podać ścieżkę znanych_hostów z opcją -f.

ravi ranjan
źródło
1
Usuwanie odpowiedniego klucza $ ssh-keygen -R {server.name.com}| $ ssh-keygen -R {ssh.server.ip.address}| $ ssh-keygen -R server.example.com
DaddyMoe,
5
W jaki sposób odpowiedź bez wyjaśnienia zyskuje tak wiele pozytywnych opinii .. bez obaw związanych z bezpieczeństwem, bez wyjaśnień .... -1
Daniel W.
4
Wydaje się również, że jest kopią drugiej odpowiedzi poniżej. Proszę mod, posprzątaj ten bałagan ...
Daniel W.
115

Ten sam błąd wystąpił po odtworzeniu obrazu Digital Ocean Ubuntu. Użyłem następującego polecenia z adresem IP mojego serwera zamiast[IP_ADDRESS]

ssh-keygen -R [IP_ADDRESS]
Ben
źródło
Dziękuję bardzo! Używałem nazwy hosta i działała ona tylko z adresem IP_ADDRESS :)
J. Lopes,
1
Zrobiło to dla mnie i powinna być zaakceptowaną odpowiedzią. Nie wiem, dlaczego są dwie kopie tej odpowiedzi, które przyszły później i obie mają więcej głosów pozytywnych.
Wylliam Judd
Twój nie był tym samym błędem; na twoim serwerze nie było SSSD. Zobacz OP.
Mercury00
39

Po ponownym zainstalowaniu serwera jego tożsamość ulegnie zmianie i zaczniesz otrzymywać tę wiadomość. Ssh nie ma możliwości dowiedzenia się, czy zmieniłeś serwer, z którym się łączy, czy też serwer został dodany do twojej sieci, aby wąchać całą twoją komunikację - więc zwraca na to uwagę.

Po prostu usuń klucz ze znanych hostów, usuwając odpowiedni wpis:

sed '4d' -i /var/lib/sss/pubconf/known_hosts

4dJest na rachunekOffending RSA ...known_hosts:4

mockinterface
źródło
1
Dzięki, ale nie wiem dlaczego, ale usuwam go i jest w nim ponownie. Próbowałem zatrzymać usługę sssd i ten efekt zniknął, ale po uruchomieniu sssd pojawia się ponownie.
Filip Dobrovolný
Wykonaj kopię zapasową katalogu ~ / .ssh, a następnie usuń go. Czy twoja usługa ciągle dodaje klucze po zdmuchnięciu ~ / .ssh?
mockinterface
Zmieniłem nazwę .ssh na .ssh_old, po nowej próbie połączenia go po prostu utwórz pusty katalog .ssh. Nadal nie mogę uczynić / var / lib / sss / pubconf / known_hosts „edytowalnym”.
Filip Dobrovolný
4
Bardziej przenośny sposób na to: sed -i -e 4d /var/lib/sss/pubconf/known_hosts
Pierz
2
Jak wykonać kopię zapasową serwera identificationw przypadku, gdy chcesz go odbudować bez powodowania zakłóceń, takich jak ten komunikat o błędzie?
Ninjaxor
38

Młot ma za zadanie usunąć każdego znanego hosta za jednym zamachem:

rm ~/.ssh/known_hosts

Mam do czynienia z tym, ponieważ używamy małych podsieci krótkotrwałych serwerów ze skoczni i często ponownie wykorzystujemy wewnętrzny adres IP serwerów, które mają ten sam klucz ssh.

Andy Hayden
źródło
Pracował dla mnie na błędnej maszynie wirtualnej, gdy zaakceptowana odpowiedź nie zadziałała.
100pic
1
Przydatne narzędzie, które można mieć w pasie, ale może to otworzyć cię na atak MitM (dokładnie to, co known_hostsma zapobiec). Zrób to tylko wtedy, gdy masz pewność, że wszystkie hosty są bezpieczne.
Freedom_Ben
26

Problem polega na tym, że wcześniej zaakceptowałeś połączenie SSH z komputerem zdalnym, a cyfrowy odcisk palca lub klucz skrótu SHA256 zmienił się od czasu ostatniego połączenia. Dlatego przy ponownej próbie SSH lub użyciu github do pobrania kodu, który również używa SSH, pojawia się błąd. Dlaczego? Ponieważ używasz tego samego adresu komputera zdalnego jak poprzednio, ale komputer zdalny odpowiada innym odciskiem palca. Dlatego możliwe jest, że ktoś fałszuje komputer, z którym wcześniej się łączyłeś. To jest problem bezpieczeństwa.

Jeśli masz 100% pewności, że komputer zdalny nie jest zagrożony, zhakowany, sfałszowany itp., Wszystko, co musisz zrobić, to usunąć wpis w pliku znane_hosty dla komputera zdalnego. To rozwiąże problem, ponieważ podczas łączenia nie będzie już niezgodności z identyfikatorami odcisków palców SHA256.

Na Macu oto co zrobiłem:

1) Znajdź linię wyjściową, która czyta RSA host key for servername:port has changed and you have requested strict checking. : Będziesz potrzebował zarówno nazwy serwera, jak i potencjalnie portu z tego wyjścia dziennika.

2) Wykonaj kopię zapasową znanego hosta SSH cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak

3) Znajdź linię, w której przechowywany jest stary odcisk palca komputera i usuń go. Możesz wyszukać konkretny odcisk palca komputera zdalnego za pomocą nazwy serwera i portu z kroku 1.nano /Users/yourmacusername/.ssh/known_hosts

4) CTRL-X, aby wyjść i wybierz Y, aby zapisać zmiany

Teraz wpisz ssh -p port servername a otrzymasz oryginalny monit, który zrobiłeś przy pierwszej próbie SSH na tym komputerze. Następnie pojawi się opcja zapisania zaktualizowanego odcisku palca SHA256 tego zdalnego komputera w pliku znanego hosta. Jeśli używasz SSH przez port 22, argument -p nie jest konieczny.

Wszelkie problemy z przywróceniem oryginalnego pliku znanego_hosta: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts

anon58192932
źródło
3
To powinno być oznaczone jako zaakceptowana odpowiedź. Wykonanie tych kroków naprawiło mój problem, podczas gdy ssh-keygen -R [IP_ADDRESS]nie działało dla mnie. Dzięki!
Yusuf Kamil AK
Tak, jeden z tych przypadków jest niesprawiedliwy, na pewno najlepsza odpowiedź. Druga i trzecia odpowiedź po prostu powtarzają to, co powiedziała pierwsza, a wszystkie mają niepełne rozwiązanie.
brasofilo
16

Jak wielu już powiedziało, użyj ssh-keygen, tj

ssh-keygen -R pong

Możesz również rozważyć tymczasowe wyłączenie sprawdzania klucza hosta:

ssh -oStrictHostKeyChecking=no root@pong
Stephen Quan
źródło
czego używam dla .ssh / config : Host ???? CheckHostIP no StrictHostKeyChecking no(3 linie, tabulowane począwszy od 2)
XXL
15

Pracuje dla mnie!

Błąd: Obrażanie klucza RSA w / var / lib / sss / pubconf / known_hosts: 4

Oznacza to, że masz obrażający klucz RSA na linii nr. 4

Rozwiązanie 1 :

1. vi /var/lib/sss/pubconf/known_hosts

2 remove line no: 4 .

3 Save and Exit, and Retry .

Rozwiązanie 2:

ssh-keygen -R "you server hostname or ip"

LUB

Rozwiązanie 3:

sed -i '4d' /root/.ssh/known_hosts

Spowoduje to usunięcie 4thwiersza /root/.ssh/known_hostsw miejscu ( -i).

Sahil Gulati
źródło
1
Działa to w przypadku pliku .ssh znane_hosty użytkownika root. Nie dotyczy / var / lib / sss / pubconf / known_hosts, który jest plikiem zarządzanym przez SSSD i wypełnionym przez zdalny serwer.
Mercury00
1
w moim przypadku z jakiegoś powodu problem wystąpił na znanych serwerach * 2 *. Wykonanie tych kroków pomogło mi się tego dowiedzieć, dzięki @Sahil Gulati!
Lucas
11

Użyłem rozwiązania mockinterface, chociaż sed -i nie do końca działał, rozwiązałem go, usuwając wiersz ręcznie za pomocą vima:

sudo vim /var/lib/sss/pubconf/known_hosts

Możesz użyć dowolnego innego edytora tekstu, ale prawdopodobnie będziesz musiał pokazać swoje uprawnienia administracyjne

3nrique0
źródło
1
Tak, usunięcie rekordu tego samego adresu IP z pliku znane_hosty rozwiąże problem.
wherby
Wpis jest natychmiast odtwarzany przez SSSD przy ponownej próbie ssh. zwróć uwagę, że sss pubconf znane_hosty to plik zarządzany, a nie jakieś lokalne repozytorium zapełniane przez lokalny serwer.
Mercury00
9

W przypadku użytkowników komputerów Mac możesz użyć -Rflagi ssh-keygenpolecenia. Szybki przykład:

ssh-keygen -R THE_IP_ADDRESS

THE_IP_ADDRESSbędąc adresem IP, do którego próbujesz ssh. A potem możesz połączyć się dobrze.

Nick Rameau
źródło
8

Jest tak, ponieważ ustawienia komputera zdalnego uległy zmianie. Usuń do tego aktualne klucze.

vim /root/.ssh/known_hosts

Usuń linię połączonego adresu IP.

miota85
źródło
7

Edytować /home/hostname /.ssh/known_hosts i usuń 4 linie i zapisz je.

Następnie uruchom ssh root@pongponownie, zobaczysz taki komunikat: Are you sure you want to continue connecting (yes/no)? yespo prostu wydrukuj yes.

Uwaga: jeśli masz jakiś problem, przeczytaj najpierw wskazówki, to pomoże.

Bruce
źródło
Najlepsza odpowiedź, która faktycznie wyjaśnia, co się dzieje.
Prometeusz
6

Inne odpowiedzi tutaj są dobre i działają, w każdym razie rozwiązałem problem, usuwając ~/.ssh/known_hosts. To z pewnością rozwiązuje problem, ale prawdopodobnie nie jest to najlepsze podejście.

tjespe
źródło
6

W moim przypadku stało się tak, ponieważ wcześniej miałem połączenie ssh z maszyną o tym samym IP (powiedzmy 192.152.51.10), a system rozważał klucz RSA (przechowywany w /home/user_name/.ssh/known_hosts) poprzedniego hosta, co spowodowało niedopasowane.

Aby rozwiązać ten problem, musisz usunąć wcześniej zapisany klucz RSA dla adresu IP 192.152.51.10 .

ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10
Prateek Joshi
źródło
5

Proste rozwiązanie jednowarstwowe, przetestowane na komputerze Mac:

sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts

Usuwa tylko docelowy adres IP hosta ssh ze znanych hostów.

gdzie 212.156.48.110 jest zastępowane adresem IP hosta docelowego.

Przyczyna : Zdarzyło się, ponieważ docelowy adres IP był już znany dla innej maszyny z powodu przekierowania portów. Usunięcie docelowego adresu IP przed połączeniem rozwiąże problem.

Helton Malambane
źródło
4

Użyj tego polecenia:

truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts
Muktesh Kumar
źródło
Dodaj wyjaśnienie, co robi polecenie, a czego nie.
Daniel W.
6
Dlaczego chcesz obciąć plik? Tracisz wszystkie informacje, nawet te, które już zweryfikowałeś. Jest to zła metoda działania na pojedynczy zmieniony klucz hosta publicznego.
Daniel W.
1
jest to całkowity hack: D, ale działa: D
Benjamin
Wskazówka: powoduje to również usunięcie wszystkich innych informacji o hoście. Jeśli uruchamiasz automatyczne skrypty ze swojego komputera (np. Wdrożenia), mogą się zepsuć, ponieważ musisz ręcznie ponownie potwierdzić wszystkie klucze hosta. Aby ostrzec innych użytkowników, którzy chcą skorzystać z najłatwiejszego rozwiązania.
Mateng
3

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).

Chaminda Bandara
źródło
3

Po prostu zrób:

cd /home/user/.ssh/-> tutaj userbędzie twoja nazwa użytkownika, /home/jon/np.

Następnie

gedit known_hosts & i usuń zawartą w nim zawartość.

Teraz sshznowu powinno działać.

Drapieżnik
źródło
3

Jeśli próbujesz połączyć się z działającym kontenerem dokującym na porcie 2222 za pomocą polecenia i pojawia się błąd

mian@tdowrick2~$ ssh pos@localhost -p 2222

Następnie, aby rozwiązać ten problem, na komputerze lokalnym (tj. Na hoście, a nie na pojemniku) przejdź do cd ~/.ssh/i otwórz known_hostsplik za pomocą edytora tekstu. Usuń wiersz zaczynający się od [localhost]:2222i zapisz plik. Teraz spróbuj ponownie ssh

mian@tdowrick2~$ ssh pos@localhost -p 2222

Błąd zniknie, ale musisz to zrobić przy każdym ponownym uruchomieniu kontenera.

Mian Asbat Ahmad
źródło
2

Moje rozwiązanie to:

  1. vi ~/.ssh/known_hosts
  2. usuń wiersz zawierający żądany podłączony ip.

Jest to lepsze niż usunięcie wszystkich known_hosts

samolot
źródło
To jest ta sama odpowiedź, co miota85 poniżej.
Daniel W.
2

Problem tylko po stronie klienta (duplikat klucza do ip):

Rozwiąż warianty:

Dla wyczyszczenia jednego adresu IP (domyślny port 22):

ssh-keygen -f -R 7.7.7.7

Dla jednego adresu IP ( domyślny port):

ssh-keygen -f -R 7.7.7.7:333

Szybko wyczyść wszystkie Ips:

cd ~; rm .ssh/known_hosts

7.7.7.7 - ssh twój serwer ip connect

333 - niestandardowy port

Fortran
źródło
2

Czasami, jeśli z jakiegokolwiek powodu musisz ponownie zainstalować serwer, podczas łączenia przez ssh stwierdzimy, że serwer mówi, że identyfikacja uległa zmianie. Jeśli wiemy, że nie jest to atak , ale przywróciliśmy system, możemy usunąć starą identyfikację ze znanych hostów za pomocą ssh-keygen:

ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

Podczas ponownego łączenia poprosimy Cię o sprawdzenie nowego odcisku palca:

ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't 
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes
BrennQuin
źródło
1

Miałem ten problem, a powód jest bardzo prosty, mam zduplikowany adres IP do logowania ssh, więc po zmodyfikowaniu tego problemu wszystko jest rozwiązane.

Wentylator
źródło
1

Miałem ten sam błąd na moim komputerze i wyczyściłem known_hostsplik, a następnie działa dobrze.

Idąc moją drogą
źródło
1
Nie chcesz go usuwać, authorized_keysgdy masz problem z known_hostsplikiem
jeb
0

ROZWIĄZANIE:

1- usuń z „$ HOME / .ssh / known_hosts” wiersz odnoszący się do hosta, z którym nie można się połączyć.

2 - wykonaj polecenie: ssh-keygen -R „NAZWA_HOSTA_HOSTA” (zastąp „NAZWA_HOSTA_IP” docelowym ip lub docelowa nazwa hosta)

3- Ponów próbę połączenia ssh (jeśli nie powiedzie się, sprawdź uprawnienia do katalogu .ssh, musi to być 700)

Czarne chmury
źródło
0

Moje rozwiązanie na UBUNTU (linux):

1. Musisz usunąć zawartość z pliku „znane_hosty”, które znajduje się w „/home/YOUR_USERNAME/.ssh/known_hosts”

2. Wygeneruj nowy klucz ssh, taki jak „ssh-keygen -t rsa -C” twó[email protected] „-b 4096”

3. Skopiuj i wklej nowy klucz ssh do repozytorium git (w moim przypadku gitlab) klucze SSH.

Mi to pasuje !

Dionis Oros
źródło
-1

AWS EC2.

Znajdź adres IP w otrzymanej wiadomości.

biegać

vim /home/ec2-user/.ssh/known_hosts

Użyj klawiszy strzałek, aby znaleźć adres IP z wiadomości i kliknij.

dd

Spowoduje to usunięcie tej linii, a następnie uruchomienie klawisza Escape

:wp

Pozwoli to zaoszczędzić, więc możesz iść.

użytkownik1503606
źródło