Verwijder de in het geheugen opgeslagen sleutel voor 192.168.1.123 op de lokale machine:

ssh-keygen -R 192.168.1.123

In mijn geval heeft ssh-keygen -R ... de waarschuwing niet gerepareerd. Ik had extra informatie zoals deze:

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

Ik heb ~/.ssh/known_hosts gewoon handmatig bewerkt en regel 8 (de “beledigingssleutel”) verwijderd. Ik probeerde opnieuw verbinding te maken, de host werd permanent toegevoegd, en alles was daarna in orde!

Ik doe veel ssh-ing rond tussen mijn LAN-computers en mijn twee webhosting-accounts, dus ik heb alle soorten van kansen gesorteerd en eindigt met SSH, inclusief authenticatieproblemen met behulp van ssh -v om te zien waar en wat er mis ging.

Aangezien ik dit probleem net heb opgelost en niet blij ben met de antwoorden, wilde ik echt weten “waarom”…

De trigger voor mijn zaak is: geïnstalleerd nieuw server OS op het werk en bij het installeren van openssh-server pakket, een nieuwe set van host-sleutels werden gegenereerd op de server van het werk. Voorheen waren al mijn server OS’s Ubuntu en deze keer is het veranderd in Debian (en ik vermoed dat er een genuanceerd verschil in permissies is).

Als alle OS’s Ubuntu waren en ik het OS van een server opnieuw installeer, krijg ik bij de eerste SSH erin, dit soort waarschuwing, die ik prefereer boven de stille waarschuwing hierboven!

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

Dan open ik ~/. ssh/bekende_hosts op de computer die de ssh initieert, verwijder die lijn, maak opnieuw verbinding en dit gebeurt:

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

Dat beetje over :11122 is het poortnummer waar ik SSH van routeer op de firewall

Ik heb backups van een voormalige Ubuntu server gecontroleerd en diff’d tegen mijn nieuwe Debian installatie:

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

Dus ja, waarschijnlijk is de host onlangs begonnen met het gebruik van ecdsa-sleutels, wat op basis van Ubuntu’s veranderingen van de laatste tijd de schuld zou zijn van een update. Ubuntu’s verschuiving van het rotsvaste linux OS waar ik op rekende is de reden waarom ik Debian deze keer heb geïnstalleerd.

Ik las een security.SE q/a op ecdsa en heb die regel al verwijderd van sshd_config mijn nieuwe Debian server. (en runde service ssh restart)

De prompt treedt elke keer op omdat de IP-adressen steeds veranderen bij het gebruik van dynamische adressering. Probeer statische IP te gebruiken, zodat u de sleutel slechts één keer hoeft toe te voegen.

ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.123

Dit moet de bestaande sleutels onder known_hosts.old vervangen en een nieuwe maken. Deze oplossing werkte voor mij in hetzelfde scenario

Ik heb de volgende regels toegevoegd aan mijn ~/.ssh/config, waardoor de strikte controle van de host op alle .lokale adressen wordt uitgeschakeld. (met DHCP adrestoewijzing, ip-adressen van mijn lokale machines veranderen altijd)

host *.local
    StrictHostKeyChecking no

Je krijgt echter nog steeds de waarschuwing, wat ik prima vind.

Als u bent ingelogd op een lokale PC zoals gebruiker John en verbonden met de server B zoals gebruiker Adolf@B en alles is OK, betekent dit niet dat alles OK is als u bent ingelogd op een lokale PC zoals gebruiker Jane en verbonden met de server B zoals gebruiker Adolf@B.

Als je wilt inloggen op server B als gebruiker Beda vanaf PC A zonder wachtwoord, probeer dan dit commando, alles vanaf PC A:

ssh-keygen -t rsa

Dit commando genereert de sleutel en slaat de sleutel op in het bestand. Laat passphrase leeg.

ssh Beda@B mkdir -p .ssh

Dit commando genereert de directory, indien deze nog niet bestaat. Anders moet u geen foutmelding afdrukken.

cd ~/.ssh

Dit commando verandert de directory in de home directory van uw gebruikers ./ssh.

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

Dit commando drukt het bestand af id_rsa. pub (uw publieke sleutel) in authorized_keys op de server.

BELANGRIJK: Beda is uw gebruikersnaam op de server waarmee u verbinding maakt, B is uw server IP.

Nu kunt u verbinding maken met de server B zonder een wachtwoord of passphrase:

ssh Beda@B

Vraag: Wat is de oorzaak van deze, …?

• Werd de ssh server host sleutel veranderd.  Wat veroorzaakte de verandering?   Het is moeilijk te zeggen.  Hier zijn enkele gissingen:

• Is sshd op myserver begonnen met ECDSA sleutels, dus het is een nieuw sleuteltype?

• Werd myserver onlangs opnieuw geïnstalleerd?

• Werd sshd op myserver onlangs opnieuw geïnstalleerd zodat een nieuwe ssh host sleutel werd gegenereerd?

• Heeft iemand de sshd hostsleutel opnieuw gegenereerd of vervangen?

• Is het IP adres van de myserver veranderd zodat een andere host op dat IP adres antwoordt?

Vraag: … en hoe los ik dat op?

Zoals anderen al hebben geantwoord, verwijder de cache van de ECDSA hostsleutel voor de myserver die uw account heeft gecached.

De draad hier kan helpen.

In wezen wilt u zowel de RSA- als de ECDSA-toetsen voor die host verwijderen en vervolgens ssh-keyscan gebruiken om ze terug te zetten in uw known_hosts-bestand op een manier die dit conflict niet zal veroorzaken. Het werkte voor mij toen ik hetzelfde probleem had.

Deze fout bleef me lang dwarszitten. Om een of andere reden maakte het verschil of ik een

ssh host

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

wees me toen op de mogelijkheid om het configuratiebestand te wijzigen. Zie mijn script https://askubuntu.com/a/949731/129227 daar voor het automatiseren van het proces.

Ik heb dit gerepareerd op een Chromebook door Secure Shell te verwijderen en opnieuw te installeren… Het werkte als een charme.

Aan mijn zijde gebeurt dit door iets wat ik beschouw als een ssh bug van nieuwere (OpenSSH_7.9p1 en hoger) clients, wanneer het probeert een veiligere ecdsa server sleutel te leren waar al een oudere rsa type sleutel bekend is. Het presenteert dan deze misleidende boodschap!

Ik weet geen goede oplossing hiervoor, de enige workaround die ik vond is het verwijderen van alle “goede maar oude rsa sleutels” zodat de client de “nieuwe veiligere ecdsa sleutels” opnieuw kan leren. Dus:

1. De eerste stap is het verwijderen van alle goede oude RSA sleutels ( Waarschuwing! Dit verliest bescherming tegen MitM ):

2. De tweede stap is dan om alle host-sleutels opnieuw te leren, wat handmatig moet gebeuren door opnieuw verbinding te maken met elk IP met behulp van ssh.

• *

Hier is wat ik waarneem:

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

Probeer nu verbinding te maken met een nieuw geïntroduceerde alias van dezelfde reeds bekende goede server:

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Bekijk het IP adres. Het is hetzelfde IP als hierboven! Het lijkt er dus op dat de (goede) sleutel van het (bekende) IP zichzelf ineens beledigt (dat is het niet, want de ssh client mixt twee incompatibele sleutels, zie hieronder).

Nu proberen we het te repareren:

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Laten we het nog eens proberen:

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF? Wat is hier gebeurd? De nieuwe verse sleutel die we van de server hebben geleerd is weer mislukt? En het probleem is zelfs van kant gewisseld?!?

Nope, het is niet de sleutel, noch de server. Alles klopt!

Het is de ssh-client die niet de juiste sleutel controleert! Entry 45 in known_hosts draagt nu een sleutel van het type ecdsa-sha2-nistp256 terwijl de sleutel, die door de client van de server werd getrokken, van het type rsa-sha2-512 is (en dus niet kan overeenkomen met de andere sleutel!).

$ sftp -v test@valentin.hilbig.de

toont:

debug1: kex: host key algorithm: rsa-sha2-512

terwijl

$ sftp -v test@gcopy.net

toont:

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

Blijkbaar heeft de ssh-client ergens een foutje! Het kan niet omgaan met een host sleutel die in meer dan één variant bestaat! Of het valt in de val om een verouderde variant van een sleutel aan te vragen.

Hoe te verhelpen?

Ik heb echt geen idee. Dit kan waarschijnlijk alleen stroomopwaarts gerepareerd worden.

Maar er is een handmatige maar onhandige workaround:

Je moet alle sporen van de oude sleutel van het type rsa handmatig verwijderen. De betreffende sleutel wordt in de uitvoer getoond, maar is niet direct gemarkeerd als het probleem:

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

check:

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

geeft

ecdsa-sha2-nistp256
ssh-rsa

dus hier is de matching hostsleutel de beledigende en de beledigende sleutel is de juiste die bewaard moet worden! Dus laten we de verkeerde (matchende) sleutel verwijderen:

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Controleer nu opnieuw:

$ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp> 

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp> 

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

YAY! Probleem eindelijk weg. Maar met enkele 100 vermeldingen in .ssh/known_hosts wordt deze “oplossing” echt een grote PITA (en een Error Prone Security Nightmare op Elm Street. YMMV).

Hier is hoe u een bekende host-vingerafdruk (van known_hosts-bestand) op een Chrome OS kunt verwijderen:

Zoek de index van de inbreukmakende host-ingang in de ssh-uitvoer als de verbinding mislukt. In de regel hieronder is bijvoorbeeld 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Open de JavaScript-console (CTRL+Shift+J) van het Secure Shell-venster en typ het volgende, waarbij INDEX wordt vervangen door de juiste waarde (bijv. 7 ):

term_.command.removeKnownHostByIndex(INDEX);

Deze oplossing is geleend van Leo Gaggl’s Blog .