Warning: Remote Host Identification Has Changed & hoe je het oplost

SSH is een beveiligd netwerkprotocol dat een versleutelde tunnel tussen systemen opzet. Het blijft populair bij ontwikkelaars die op afstand toegang tot computers nodig hebben zonder een grafische gebruikersinterface. Hoewel SSH al tientallen jaren bestaat en talloze gebruikers betrouwbaar heeft bediend, kan het nog steeds door bepaalde fouten worden getroffen.

Veel van deze fouten zijn bekend in de SSH-community en de oplossingen zijn goed gedocumenteerd. Hieronder vallen firewallonverenigbaarheid, Problemen met het injecteren van SSH-publieke sleutels, Problemen met de bestandssleutelmodus van SSH, en de foutmelding "Warning: Remote Host Identification Has Changed".

Deze fout treedt op in alle grote besturingssystemen, waaronder Windows, Linux en macOS. De oorzaak van het probleem kan een legitiem beveiligingsprobleem zijn in plaats van een technische storing. In dit artikel leggen we uit waarom dit gebeurt, wat het betekent voor de beveiliging van je SSH-verbinding en hoe je het oplost op elk belangrijk platform.

Wat veroorzaakt de melding "Warning: Remote Host Identification Has Changed" (en moet je je zorgen maken)?

De melding "Warning: Remote Host Identification Has Changed" verschijnt wanneer de SSH-publieke sleutel opgeslagen in je known_hosts bestand niet overeenkomt met de sleutel die de server momenteel presenteert. Dit verschil activeert het ingebouwde beveiligingsmechanisme van SSH om je te beschermen tegen mogelijke bedreigingen.

Legitieme redenen voor het wijzigen van de hostsleutel

Er zijn verschillende onschuldige redenen waarom de hostsleutel van een server kan veranderen. Soms zie je varianten zoals "RSA host key has changed", afhankelijk van het specifieke sleuteltype dat wordt gebruikt.

Infographic met serverwijzigingen die SSH-hostsleutels aanpassen, waaronder OS-upgrades, server-rebuilds, het terugzetten van back-ups, migratie van fysiek naar virtueel en het resetten van de SSH-configuratie.
Servergerelateerde wijzigingen:

Het besturingssysteem van de server is opnieuw geïnstalleerd of geüpgraded
De server is opnieuw opgebouwd of hersteld vanuit een back-up
De SSH-configuratie van de server is gereset
De fysieke of virtuele machine is vervangen
Servermigratie naar nieuwe hardware

Wijzigingen in netwerkconfiguratie:

Cloud-providers hergebruiken IP-adressen na verloop van tijd, of uw verbinding loopt via een load balancer.
DHCP heeft een IP-adres opnieuw toegewezen aan een andere machine
Het IP-adres van een buiten gebruik gestelde server is toegewezen aan een nieuw systeem
DNS-records zijn bijgewerkt om naar een andere server te verwijzen

Netwerkdiagram waarop een DHCP-server dynamische IP-adressen toewijst aan virtuele machines, waarbij het buiten gebruik stellen en opnieuw uitgeven van servers SSH-hostsleutelconflicten veroorzaakt.

Sleutelbeheeracties:

Systeembeheerders hebben hostsleutels handmatig opnieuw gegenereerd om veiligheidsredenen
SSH-serversoftware is opnieuw geïnstalleerd
Beveiligingsbeleid vereiste sleutelrotatie

Het is belangrijk te weten dat het wijzigen van gebruikerswachtwoorden geen invloed heeft op hostsleutels. Dit zijn afzonderlijke authenticatiemechanismen. Hostsleutels veranderen alleen wanneer de server zelf of de SSH-configuratie wordt gewijzigd.

Wanneer u de waarschuwing serieus moet nemen

Hoewel veel wijzigingen van hostsleutels legitiem zijn, kan dit op een echte beveiligingsdreiging wijzen. Wees alert als:

U geen wijzigingen aan de server heeft aangebracht en niets weet van gepland onderhoud
U de reden voor de sleutelwijziging niet kunt verifiëren bij de serverbeheerder
De server wordt benaderd via openbare netwerken of niet-vertrouwde verbindingen
U verbinding maakt met productiesystemen of servers met gevoelige gegevens

Gesplitst scherm met een vergelijking tussen legitieme SSH-wijzigingen in groen en beveiligingsdreigingsscenario's in rood, met een gehulde figuur die man-in-the-middle-aanvallen symboliseert.
Man-in-the-middle-aanvallen komen weliswaar relatief zelden voor, maar ze bestaan wel. Bij dit soort aanvallen plaatst een aanvaller zich tussen uw computer en de legitieme server, waardoor al het verkeer wordt onderschept.

Menselijke fout en social engineering zijn verantwoordelijk voor 68% van de beveiligingsinbreuken, wat waakzaamheid essentieel maakt. Je kunt je systemen verder beschermen door meer te leren over het voorkomen van brute-force aanvallen.

Recente cijfers van IBM tonen aan dat de gemiddelde wereldwijde kosten van een gegevenslek in 2025 uitkwamen op $4,44 miljoen, met een gemiddelde detectietijd van acht maanden. Dit laat zien waarom het host key-verificatiemechanisme van SSH bestaat en waarom je deze waarschuwingen nooit zonder onderzoek mag negeren.

Hoe controleer je of de waarschuwing veilig is

Voer de volgende verificatiestappen uit voordat je het probleem oplost:

Stroomdiagram met vijf verificatiemethoden om legitieme SSH host key-wijzigingen te bevestigen, waaronder teamoverleg, contact met de hostingprovider, beveiligde kanalen en vingerafdruksvergelijking.

Overleg met je team: Als je servertoegang deelt, vraag collega's dan of zij wijzigingen hebben aangebracht
Bekijk de serverlogs: Controleer onderhoudsregistraties of changelogs op recente activiteit
Neem contact op met je hostingprovider: Als je cloudservices gebruikt, verifieer dan of er onderhoud heeft plaatsgevonden
Gebruik een beveiligd kanaal: Maak indien mogelijk verbinding via een bekend beveiligd netwerk om de vingerafdruk te verifiëren
Vingerafdrukken vergelijken: Sommige hostingproviders tonen de huidige SSH-vingerafdrukken in hun configuratiepaneel

Als je kunt bevestigen dat de key-wijziging legitiem was, kun je de oude key veilig verwijderen en de nieuwe accepteren.

Als je dynamische IP-heroewijzing of host key-conflicten wilt vermijden, speelt de infrastructuur die je kiest een grote rol.

Cloudzy biedt SSH VPS hosting met dedicated statische IP's. Je draait op AMD Ryzen 9-processors met NVMe-opslag voor directe opdrachtuitvoering. Ons netwerk bereikt 40 Gbps op 12 wereldwijde locaties. Bovendien is gratis DDoS-bescherming inbegrepen om je verbinding te beveiligen.

De fout 'Remote Host Identification Has Changed' oplossen

De oplossing is eenvoudig: verwijder de oude key-record uit je systeem. Dit lost de mismatch op en stelt je in staat de nieuwe key op te slaan bij de volgende verbinding. Bekijk onze gids over SSH-clients voor meer tools.

Bovendien doe je dit met één enkel commando of door het bestand handmatig te bewerken.

Methode 1: De opdrachtregel (snelste methode)

Deze methode werkt voor macOS, Linux en Windows 10+ (met OpenSSH). Dit is de snelste manier om de fout op te lossen. Meer informatie vind je in de ssh-keygen man pagina.

Open je terminal.
Voer dit commando uit (vervang hostname door het IP-adres of domein van je server):

ssh-keygen -R hostname

This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Als je liever een teksteditor gebruikt, kun je de sleutel handmatig verwijderen. De foutmelding geeft meestal precies aan welk regelnummer je moet verwijderen.

Open je terminal en bewerk het bestand met Nano:

nano ~/.ssh/known_hosts

Zoek de regel uit je foutmelding. Verwijder die regel en druk vervolgens op Ctrl + X en Y om op te slaan.

macOS terminalvenster met de nano-teksteditor en het known_hosts-bestand geopend, waarbij de te verwijderen regel is gemarkeerd en genummerde stappen met opslaginstructies worden weergegeven.

Oplossing voor Windows

Windows-gebruikers werken doorgaans met de ingebouwde OpenSSH-client of met PuTTY.

Optie 1: Windows OpenSSH (Windows 10/11)

Op Windows 10 en 11 is OpenSSH een optionele functie. Voeg deze toe via Instellingen > Apps > Optionele functies. Server 2025 bevat de client al, maar je moet deze nog wel inschakelen.

Als je PowerShell of de opdrachtprompt gebruikt, werkt het ssh-keygen commando uit Methode 1 hier ook.

Als je het bestand liever handmatig wilt bewerken:

Druk Windows-toets + R.
Soort %USERPROFILE%\.ssh en druk Enter.
Open het known_hosts bestand met Notepad.
Verwijder de regel die de fout veroorzaakt en sla het bestand op.

Voor het correct beheren van sleutels, zie onze handleiding over SSH-sleutels aanmaken in Windows.

Optie 2: PuTTY gebruiken

PuTTY slaat sleutels op in het Windows-register in plaats van in een bestand.

Open de Register-editor (druk op Windows-toets + R, type regediten klik op Enter).
Navigeer naar: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Zoek het item dat overeenkomt met de hostnaam of het IP-adres van je server.
Klik er met de rechtermuisknop op en kies Verwijderen.

Windows PowerShell-opdracht die de SSH host key verwijdert via de SSH-opdrachtregel, met File Explorer die het bijgewerkte known_hosts-bestand toont en PuTTY Registry Editor met een bevestigingsdialoog voor het verwijderen van de host key.

Oplossing voor Linux

De ssh-keygen commando dat we hebben behandeld in Methode 1 is de standaardmethode om dit op Linux op te lossen. Het is snel en wordt native ondersteund.

Handmatig bewerken

Als je de bestandsinhoud wilt bekijken, kun je het openen met een teksteditor zoals Nano.

Open je terminal.
Soort nano ~/.ssh/known_hosts en druk Enter.
Zoek het regelnummer dat in je foutmelding staat.
Verwijder de regel en druk daarna op Ctrl + X en Y om op te slaan.

Je kunt ook Vim (vim ~/.ssh/known_hostsgebruiken als je daar vertrouwd mee bent.

Linux terminal met ssh-keygen-opdrachten om SSH host keys te verwijderen op basis van hostnaam en IP-adres, met bevestiging van succes en voorbeelden van het known_hosts-bestand.
Waarschuwing over het uitschakelen van controles

Je kunt SSH dwingen verbinding te maken zonder verificatie, maar dat brengt risico's met zich mee. Het omzeilt de bescherming tegen man-in-the-middle-aanvallen.

Gebruik deze aanpak alleen voor lokale tests op vertrouwde netwerken. Voor macOS en Linux gebruik je het volgende:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Als je op Windows werkt, werkt het Unix-pad niet. Je moet NUL gebruiken om de bypass te laten werken:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

Gebruik deze overrides niet op publieke verbindingen of productieservers.

Het oplossen van key-conflicten is regulier onderhoud, maar je kunt meer doen om je verbinding te beveiligen. Bots richten zich vaak op de standaardpoort 22 met brute-force-aanvallen. Je kunt het meeste van dit achtergrondverkeer vermijden door SSH-poorten te wijzigen in Linux naar iets minder voorspelbaars.

Diagram van een man-in-the-middle-aanval op SSH: een aanvaller onderschept de verbinding tussen client en server, met vergelijking van de aanvaller-key en de server key, en risico's zoals datadiefstal en financieel verlies uitgelicht.

Gebruik deze methode nooit voor productieservers of via onbetrouwbare netwerken.

Hoe je de melding "Remote Host Identification Has Changed" voortaan voorkomt

Je kunt legitieme host key-wijzigingen niet altijd voorkomen, maar je kunt verstoringen minimaliseren en betere beveiligingspraktijken hanteren.

Snelreferentiegids

Je rol	Belangrijkste strategieën
Systeembeheerders	Maak back-ups van keys, documenteer wijzigingen, gebruik certificaten en roteer keys regelmatig
Normale Gebruikers	Houd een inventaris bij, verifieer via beveiligde kanalen en monitor de logs
Cloudomgeving Gebruikers	Gebruik DNS-namen, zet providertooling in en implementeer infrastructure as code

Infographic over best practices voor SSH-sleutelbeheer: gebruik SSH-certificaten, DNS-namen, Infrastructure as Code, maak back-ups van hostsleutels, documenteer wijzigingen en overweeg bastionhosts.

Voor systeembeheerders

Back-up van hostsleutels: Sla sleutels op uit /etc/ssh/ voordat je het OS herinstalleert. Herstel ze daarna om waarschuwingen voor je gebruikers te voorkomen.

Documenteer geplande wijzigingen: Informeer gebruikers van tevoren over sleutelwijzigingen en deel de nieuwe vingerafdrukken via een beveiligd kanaal. Zo kunnen ze de verbinding verifiëren.

Gebruik SSH-certificaten: Grote teams zetten beter een centrale certificaatautoriteit op. Die ondertekent hostsleutels en maakt handmatige verificatie overbodig.

Implementeer sleutelrotatie: Plan je hostsleutelwijzigingen vooruit. Voorspelbare updates zijn voor je team eenvoudiger te verwerken dan onverwachte.

Voor gewone gebruikers

Voorraadbeheer: Houd zelf een overzicht bij van servervingerafdrukken, of gebruik de beveiligde documentatie van je team.

Verifieer via out-of-band: Bevestig sleutels via een betrouwbare bron zoals de cloudconsole, niet via informele berichten.

Logboeken controleren: Controleer je lokale SSH-logs regelmatig op afwijkende verbindingspatronen of herhaalde fouten.

Gebruik configuratiebeheer: Gebruik SSH-configuratiebestanden om dynamische ontwikkelomgevingen te beheren zonder de beveiligingsinstellingen te verlagen.

Voor dynamische cloudomgevingen

Gebruik DNS-namen: Maak verbinding via hostnamen in plaats van IP-adressen. Zo blijft de configuratie consistent wanneer het onderliggende adres verandert.

Gebruik cloudtooling: Haal actuele vingerafdrukken op via de providerconsole. Verifieer sleutels met deze tooling voordat je wijzigingen accepteert.

Infrastructuur als Code Automatiseer sleutelverificatie met tools zoals Terraform. Voor geavanceerde configuraties kun je ook SSH SOCKS5-proxies gebruiken.

Bastion-hosts: Zet jumpservers op met vaste sleutels. Deze fungeren als beveiligde toegangspunten tot je dynamische infrastructuur.

Conclusie

De melding "Warning: Remote Host Identification Has Changed" is een belangrijke beveiligingsfunctie van SSH, geen fout die je kunt negeren. De melding verschijnt vaak om legitieme redenen, zoals serverherstel of configuratiewijzigingen, maar speelt ook een cruciale rol in de bescherming tegen man-in-the-middle-aanvallen en ongeautoriseerde toegang.

Wanneer je deze melding ziet, controleer eerst de oorzaak voordat je verdergaat. In de meeste gevallen is de oplossing eenvoudig: verwijder de oude hostsleutel via de methode die voor jouw besturingssysteem van toepassing is, en accepteer de nieuwe sleutel bij je volgende verbinding.

Als je begrijpt hoe SSH-hostsleutels werken en de aanbevolen werkwijzen volgt, combineer je veiligheid en gemak in je workflows voor externe toegang. Meer informatie over het veilig overdragen van bestanden vind je bij bestanden kopiëren via SSH.

Veelgestelde vragen

Moet ik de melding "Warning: Remote Host Identification Has Changed" serieus nemen?

Ja, neem de melding serieus. Het betekent dat de identiteit van de server is veranderd, wat kan wijzen op een man-in-the-middle-aanval of gewoon op regulier onderhoud. Verifieer de wijziging altijd bij je beheerder of provider voordat je de nieuwe sleutel accepteert.

Wat veroorzaakt de melding "Warning: Remote Host Identification Has Changed"?

Deze melding verschijnt wanneer de huidige vingerafdruk van de server niet overeenkomt met de opgeslagen waarde in je known_hosts-bestand. Veelvoorkomende oorzaken zijn herinstallaties van het besturingssysteem, wijzigingen van IP-adressen of het resetten van SSH-configuraties. In zeldzame gevallen wijst het op een actieve man-in-the-middle-aanval.

Kan deze fout optreden op verschillende besturingssystemen?

Ja, deze melding kan optreden op alle besturingssystemen die SSH gebruiken, waaronder Windows, macOS en Linux. De oorzaak ligt in de beveiligingsverificatie van het SSH-protocol. De manier om het op te lossen verschilt per platform, maar de onderliggende beveiligingslogica is op elk systeem identiek.

Hoe weet ik of een hostsleutelwijziging legitiem is of op een aanval wijst?

Controleer of er recent onderhoud, OS-updates of IP-wijzigingen hebben plaatsgevonden. Verifieer de nieuwe vingerafdruk via een betrouwbare bron, zoals de console van je cloudprovider of een bevestiging van je systeembeheerder, voordat je verbinding maakt.

Maakt het uitschakelen van hostsleutelcontrole SSH handiger?

Het is handiger, maar onveiliger. Door controles uit te schakelen, vervalt de bescherming tegen man-in-the-middle-aanvallen en worden verbindingen kwetsbaar. Gebruik deze instelling alleen in geïsoleerde testomgevingen, nooit op productieservers of openbare netwerken met gevoelige gegevens.

Hoe vaak moeten SSH-hostsleutels worden gewijzigd?

Hostsleutels hoeven doorgaans niet regelmatig te worden gewisseld. Verander ze alleen na een serverherinstallatie, een nieuwe OS-installatie of een beveiligingsincident. Frequente wijzigingen verstoren gebruikers, dus prioriteer stabiliteit en communiceer wijzigingen duidelijk wanneer ze noodzakelijk zijn.

Waarschuwing: Remote Host Identification Has Changed en hoe je dit oplost