Jak naprawić ostrzeżenie o kluczu hosta ECDSA

Próbuję skonfigurować SSH bez hasła na serwerze Ubuntu ssh-copy-id myuser@myserver, ale pojawia się błąd:

Ostrzeżenie: klucz hosta ECDSA dla „myserver” różni się od klucza dla adresu IP „192.168.1.123”

Co to powoduje i jak to naprawić? Próbowałem usunąć .sshkatalog na komputerze zdalnym i uruchomić ssh-keygen -R "myserver"lokalnie, ale to nie rozwiązuje błędu.

Usuń buforowany klucz dla 192.168.1.123komputera lokalnego:

ssh-keygen -R 192.168.1.123

W moim przypadku ssh-keygen -R ...nie naprawiłem ostrzeżenia. Miałem dodatkowe informacje takie jak to:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Po prostu ręcznie zmodyfikowałem ~/.ssh/known_hostsi usunąłem wiersz 8 („klucz obrażający”). Próbowałem połączyć się ponownie, host został dodany na stałe, a potem wszystko było w porządku!

Robię dużo sshing między moimi komputerami LAN i moimi dwoma kontami hostingowymi, więc uporządkowałem wszelkiego rodzaju szanse i kończy się na SSH, w tym problemy z uwierzytelnianiem, ssh -vaby zobaczyć, gdzie i co poszło źle.

Właśnie rozwiązałem ten problem i nie jestem zadowolony z odpowiedzi, chciałem naprawdę wiedzieć, „dlaczego” sam…

Wyzwalaczem w moim przypadku jest: zainstalowany nowy system operacyjny serwera w pracy, a po zainstalowaniu pakietu openssh-server na serwerze roboczym wygenerowano nowy zestaw kluczy hosta. Wcześniej wszystkie moje systemy operacyjne serwera były Ubuntu i tym razem zmieniły się na Debian (i podejrzewam, że istnieje niuansowa różnica w uprawnieniach).

Kiedy wszystkie systemy operacyjne były Ubuntu i ponownie instaluję system operacyjny serwera, po pierwszym SSH dostaję tego rodzaju ostrzeżenie, które wolę niż ciche ostrzeżenie powyżej!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Następnie otwieram się ~/.ssh/known_hostsna komputerze inicjując ssh, usuwam ten wiersz, ponownie się łączy i tak się dzieje:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

_{Ten kawałek około: 11122 to numer portu, z którego kieruję SSH na zaporze}

Sprawdziłem kopie zapasowe z poprzedniego serwera Ubuntu i różniłem się od mojej nowej instalacji Debian:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Więc tak, prawdopodobnie host zaczął ostatnio używać kluczy ecdsa, co w oparciu o zmiany Ubuntu ostatnio, winiłbym za aktualizację. Odejście Ubuntu od solidnego systemu Linux, na który liczyłem, spowodowało, że tym razem zainstalowałem Debiana.

Przeczytałem q.a security.SE na ecdsa i już usunąłem ten wiersz z sshd_configmojego nowego serwera Debian. (i pobiegł service ssh restart)

Monit pojawia się za każdym razem, ponieważ adresy IP zmieniają się cały czas podczas korzystania z dynamicznego adresowania. Spróbuj użyć statycznego adresu IP, aby klucz mógł zostać dodany tylko raz.

ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Powinno to zastąpić istniejące klucze w pliku znane_hosty.old i utworzyć nowy. To rozwiązanie działało dla mnie w tym samym scenariuszu

Dodałem następujące wiersze do mojego ~ / .ssh / config, wyłączając w ten sposób ścisłe sprawdzanie hosta dla wszystkich adresów lokalnych. (przy przydzielaniu adresów DHCP adresy IP moich komputerów lokalnych zawsze się zmieniają)

host *.local
    StrictHostKeyChecking no

Nadal jednak pojawia się ostrzeżenie, które jest dla mnie w porządku.

Czy używasz tego samego użytkownika do łączenia?

Jeśli jesteś zalogowany na lokalnym komputerze, takim jak użytkownik John i podłączony do serwera B, jak użytkownik Adolf @ B i wszystko jest w porządku, nie oznacza to, że wszystko jest w porządku, jeśli jesteś zalogowany na lokalnym komputerze, takim jak użytkownik Jane i łączysz się z serwerem B jak użytkownik Adolf @ B .

Jeśli chcesz zalogować się na serwerze B jako użytkownik Beda z komputera A bez hasła, wypróbuj to polecenie, wszystko z komputera A :

ssh-keygen -t rsa

To polecenie generuje klucz i zapisuje klucz w pliku. Proszę pozostawić puste hasło .

ssh Beda@B mkdir -p .ssh

To polecenie tworzy katalog, jeśli jeszcze nie istnieje. W przeciwnym razie nie drukuj komunikatu o błędzie.

cd ~/.ssh

To polecenie zmienia katalog na katalog domowy użytkowników ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

To polecenie drukuje plik id_rsa.pub (twój klucz publiczny) w uprawnione klucze na serwerze.

WAŻNE: Beda to nazwa użytkownika na serwerze, z którym się łączysz, B to adres IP twojego serwera.

Teraz możesz połączyć się z serwerem B bez hasła lub hasła:

ssh Beda@B

Wątek tutaj może pomóc.

Zasadniczo chcesz usunąć zarówno klucze RSA, jak i ECDSA dla tego hosta, a następnie użyj ich, ssh-keyscanaby umieścić je z powrotem w known_hostspliku w sposób, który nie spowoduje konfliktu. To działało dla mnie, gdy miałem ten sam problem.

Pytanie: Co to powoduje ...?

Tak więc zmienił się klucz hosta serwera ssh. Co spowodowało zmianę? Trudno powiedzieć. Oto kilka domysłów:

• Czy sshd na moim serwerze zaczął używać kluczy ECDSA, więc jest to nowy typ klucza?
• Czy mój serwer został niedawno ponownie zainstalowany?
• Czy sshd na moim serwerze niedawno został ponownie zainstalowany, więc wygenerowano nowy klucz hosta ssh?
• Czy ktoś ponownie wygenerował lub zastąpił klucz hosta sshd?
• Czy adres IP mojego serwera zmienił się, tak że inny host odpowiada na ten adres IP?

Pytanie: ... i jak to naprawić?

Jak już inni odpowiedzieli, usuń buforowany klucz hosta ECDSA dla mojego serwera, który jest buforowany na koncie.

Ten błąd denerwował mnie przez długi czas. Z jakiegoś powodu miało to znaczenie, czy zrobiłbym to

ssh host

lub

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

następnie wskazał mi opcję zmiany pliku konfiguracyjnego. Zobacz mój skrypt https://askubuntu.com/a/949731/129227 tam do automatyzacji procesu.

Naprawiłem to na Chromebooku, odinstalowując i ponownie instalując Secure Shell ... To działało jak urok.

Oto jak usunąć znany odcisk palca hosta (z known_hostspliku) w systemie operacyjnym Chrome:

Znajdź indeks niepoprawnego wpisu hosta na wyjściu ssh, gdy połączenie się nie powiedzie. Na przykład w poniższym wierszu indeks obrażeń to 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Otwórz konsolę JavaScript ( CTRL+ Shift+ J) okna Bezpiecznej powłoki i wpisz następujące, zastępując INDEXodpowiednią wartością (np. 7 ):

term_.command.removeKnownHostByIndex(INDEX);

To rozwiązanie zostało zapożyczone z bloga Leo Gaggl .