SSH meldt ‘REMOTE HOST IDENTIFICATION HAS CHANGED!’ en ‘Host key verification failed’? Lees wanneer het onschuldig is, wanneer niet, en hoe je het oplost.
Elke SSH-server heeft een eigen sleutel, de host key. De eerste keer dat je verbinding maakt, vraagt SSH of je die server vertrouwt en bewaart hij de vingerafdruk (fingerprint) van die sleutel in ~/.ssh/known_hosts. Bij elke volgende verbinding vergelijkt SSH de sleutel met wat het heeft bewaard. Is die anders, dan stopt SSH met de grote waarschuwing REMOTE HOST IDENTIFICATION HAS CHANGED! en weigert het met Host key verification failed.
Die controle beschermt je tegen een ‘man-in-the-middle’-aanval: iemand die zich tussen jou en de server plaatst en zich voordoet als die server, om je wachtwoord of je verkeer te onderscheppen. Daarom is de melding zo nadrukkelijk. Meestal is er echter een onschuldige reden: de server is opnieuw geïnstalleerd, verhuisd naar een andere machine, het IP-adres is aan een andere server gegeven, of de beheerder heeft de sleutels bewust vervangen.
Host key verification failed komt ook zonder de grote waarschuwing voor, bijvoorbeeld in een script, cronjob of buildstraat. Dan is de server nog helemaal niet bekend in known_hosts en kan SSH je niet vragen of je hem vertrouwt, omdat er niemand is om ‘yes’ te typen. Of het bestand known_hosts is niet leesbaar voor de gebruiker waaronder het script draait.
@-tekens met ‘REMOTE HOST IDENTIFICATION HAS CHANGED’ en een regel ‘Offending … key in …known_hosts:nummer’.Menunamen kunnen per versie of toestel iets anders heten. Loop de stappen op volgorde af en stop zodra het werkt.
Typ geen wachtwoord en ga niet verder. Vraag je af of er iets aan de server is gebeurd: opnieuw geïnstalleerd, verhuisd, een nieuw IP-adres, een andere server achter dezelfde naam. Vraag het de beheerder of je hostingpartij als je het niet zelf weet. Is er geen verklaring, behandel het dan als een mogelijk probleem.
SSH toont in de waarschuwing de vingerafdruk van de nieuwe sleutel, bijvoorbeeld SHA256:…. Vergelijk die met een vingerafdruk die je via een ánder kanaal krijgt: de beheerder die hem op de server zelf opvraagt, het beheerpaneel of de console van je server, of bij GitHub en GitLab de officiële documentatie met hun vingerafdrukken. Komen ze overeen, dan is de wijziging echt.
# op de server zelf (via console of bestaande sessie):
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubIs de nieuwe sleutel bevestigd, verwijder dan de oude regel. ssh-keygen -R haalt alle bewaarde sleutels voor die naam weg en maakt een reservekopie (known_hosts.old). Doe het voor de hostnaam én voor het IP-adres als je beide gebruikt, en vermeld een afwijkende poort tussen blokhaken.
ssh-keygen -R server.voorbeeld.nl
ssh-keygen -R 203.0.113.10
ssh-keygen -R "[server.voorbeeld.nl]:2222"Maak opnieuw verbinding. SSH vraagt dan ‘Are you sure you want to continue connecting (yes/no/[fingerprint])?’ en toont de vingerafdruk. Controleer die nog één keer tegen wat je in stap 2 kreeg en typ pas dan yes. Je kunt ook de vingerafdruk zelf plakken; SSH vergelijkt hem dan voor je.
ssh gebruiker@server.voorbeeld.nl
# voor Git-hosting:
ssh -T git@github.comEen script kan geen vraag beantwoorden. Voeg de sleutel daarom eenmalig en gecontroleerd toe aan known_hosts van de gebruiker waaronder het script draait (dat is vaak een andere gebruiker dan jij, bijvoorbeeld www-data of root). Met ssh-keyscan haal je de sleutel op; vergelijk de vingerafdruk met ssh-keygen -lf voordat je hem toevoegt. Met ssh-keygen -F kijk je of een host al bekend is.
ssh-keyscan -t ed25519 server.voorbeeld.nl > /tmp/hostkey
ssh-keygen -lf /tmp/hostkey
cat /tmp/hostkey >> ~/.ssh/known_hosts
ssh-keygen -F server.voorbeeld.nlDraait het script onder een andere gebruiker, kijk dan of die gebruiker een eigen ~/.ssh/known_hosts heeft en die kan lezen. Een bestand dat van root is in de map van een andere gebruiker, geeft ook ‘Host key verification failed’.
ls -l ~/.ssh/known_hosts
sudo -u www-data ssh -T git@github.comInstalleer je een server opnieuw, bewaar dan de oude host keys (/etc/ssh/ssh_host_*) en zet ze terug, of laat gebruikers vooraf weten dat de sleutel verandert en wat de nieuwe vingerafdruk is. Zo leer je niemand om de waarschuwing blind weg te klikken.
Let op: Zet StrictHostKeyChecking niet uit en verwijs UserKnownHostsFile niet naar /dev/null om de melding kwijt te raken. Dan schakel je precies de bescherming uit die je tegen een onderschepte verbinding moet waarschuwen, ook voor alle volgende keren.
Je kunt aan de melding zelf niet zien of er iets kwaadaardigs gebeurt. Het verschil zit in de verklaring die je ervoor hebt.
Bij twijfel: log niet in, gebruik geen wachtwoord en neem contact op met de beheerder via een ander kanaal.
Kom je er met deze stappen niet uit, of wil je het liever niet zelf doen? We kijken online mee of komen langs. Hulp op afstand kost €20 per uur; komen we langs, dan is de prijs op aanvraag. Je weet vooraf waar je aan toe bent.
Schrijf kort wat er misgaat en wat je al hebt geprobeerd. Kies of we bellen, online meekijken of langskomen.
Nee, meestal is de server opnieuw geïnstalleerd of verhuisd. Maar je kunt het pas weten als je de nieuwe vingerafdruk via een ander kanaal hebt gecontroleerd.
Met ssh-keygen -R hostnaam. Dat haalt de oude regels voor die host uit known_hosts en maakt een reservekopie.
Liever niet. Daarmee accepteer je voortaan elke sleutel, ook die van een aanvaller. Zet in scripts de juiste sleutel vooraf in known_hosts.
De cronjob draait vaak onder een andere gebruiker, met een eigen known_hosts waarin de server nog niet staat. Voeg de sleutel voor die gebruiker toe.
Hulp nodig van een mens? Website-onderhoud · Hosting en onderhoud · WordPress-support · Alle oplossingen