SSH is een beveiligd netwerkprotocol dat een gecodeerde tunnel tussen systemen creëert. Het blijft populair bij ontwikkelaars die externe toegang tot computers nodig hebben zonder dat een grafische gebruikersinterface nodig is. Hoewel SSH al tientallen jaren bestaat en talloze gebruikers op betrouwbare wijze heeft bediend, kan het nog steeds door bepaalde fouten worden beïnvloed.
Veel van deze fouten zijn bekend geworden in de SSH-gemeenschap en hun oplossingen zijn uitgebreid gedocumenteerd. Deze omvatten incompatibiliteit met firewalls, Problemen met de injectie van SSH-openbare sleutels, Problemen met de SSH-bestandssleutelmodusen de foutmelding 'Waarschuwing: externe hostidentificatie is gewijzigd'.
Deze fout treedt op bij alle belangrijke besturingssystemen, waaronder Windows, Linux en macOS. De oorzaak van het probleem kan eerder een legitiem beveiligingsprobleem zijn dan een eenvoudig technisch probleem. In dit artikel leggen we uit waarom dit gebeurt, wat dit betekent voor de veiligheid van uw SSH-verbinding en hoe u dit op elk groot platform kunt oplossen.
Wat veroorzaakt de waarschuwing: de identificatie van de externe host is veranderd (en moet u zich zorgen maken?)
De “Waarschuwing: Remote Host Identification Has Changed” verschijnt wanneer de openbare SSH-sleutel is opgeslagen in uw bekende_hosts bestand komt niet overeen met de sleutel die de server momenteel presenteert. Deze discrepantie activeert het ingebouwde beveiligingsmechanisme van SSH om u te beschermen tegen mogelijke bedreigingen.
Legitieme redenen voor wijzigingen in de hostsleutel
Verschillende onschuldige redenen verklaren waarom de hostsleutel van een server kan veranderen. Soms zie je variaties zoals 'RSA-hostsleutel is gewijzigd', afhankelijk van het specifieke sleuteltype dat wordt gebruikt.

Servergerelateerde wijzigingen:
- Het besturingssysteem van de server is opnieuw geïnstalleerd of geüpgraded
- De server is opnieuw opgebouwd of hersteld vanaf een back-up
- De SSH-configuratie van de server is opnieuw ingesteld
- De fysieke of virtuele machine werd vervangen
- Servermigratie naar nieuwe hardware
Wijzigingen in netwerkconfiguratie:
- Cloudproviders recyclen IP-adressen in de loop van de 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 zodat ze naar een andere server verwijzen

Sleutelbeheeracties:
- Systeembeheerders hebben om veiligheidsredenen de hostsleutels handmatig opnieuw gegenereerd
- SSH-serversoftware is opnieuw geïnstalleerd
- Beveiligingsbeleid vereiste sleutelroulatie
Het is belangrijk om te beseffen dat wijzigingen in het gebruikerswachtwoord geen invloed hebben op de hostsleutels. Deze vertegenwoordigen afzonderlijke authenticatiemechanismen. Hostsleutels veranderen alleen wanneer de server zelf of de SSH-configuratie ervan wordt gewijzigd.
Wanneer moet u de waarschuwing serieus nemen?
Hoewel veel wijzigingen in de hostsleutel legitiem zijn, kan dit duiden op een reële bedreiging voor de veiligheid. U moet zich zorgen maken als:
- U heeft geen wijzigingen aangebracht aan de server en u bent niet op de hoogte van gepland onderhoud
- U kunt de reden voor de sleutelwijziging niet verifiëren bij de serverbeheerder
- De server is toegankelijk via openbare netwerken of niet-vertrouwde verbindingen
- U maakt verbinding met productiesystemen of servers die gevoelige gegevens bevatten

Man-in-the-middle-aanvallen komen weliswaar relatief zelden voor. Bij dergelijke aanvallen positioneert een tegenstander zich tussen uw computer en de legitieme server en onderschept al het verkeer.
Menselijke fout en social engineering zijn verantwoordelijk voor 68% van de inbreuken op de beveiliging, waardoor waakzaamheid essentieel is. U kunt uw systemen verder beschermen door meer te leren preventie van brute force-aanvallen.
Recente statistieken van IBM laten zien dat de mondiale gemiddelde kosten van een datalek bedroeg $4,44 miljoen in 2025, met een detectietijd van gemiddeld acht maanden. Dit laat zien waarom het verificatiemechanisme voor de hostsleutel van SSH bestaat en waarom u deze waarschuwingen nooit zonder onderzoek mag negeren.
Hoe u kunt controleren of de waarschuwing veilig is
Voer de volgende verificatiestappen uit voordat u doorgaat met het oplossen van het probleem:

- Neem contact op met uw team: Als u de servertoegang deelt, vraag dan aan collega's of zij wijzigingen hebben aangebracht
- Serverlogboeken bekijken: Controleer onderhoudsgegevens of wijzig logboeken voor recente activiteiten
- Neem contact op met uw hostingprovider: Als u cloudservices gebruikt, controleer 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 geven huidige SSH-vingerafdrukken weer in hun controlepanelen
Als u kunt bevestigen dat de sleutelwijziging legitiem was, kunt u veilig doorgaan met het verwijderen van de oude sleutel en het accepteren van de nieuwe.
Als u dynamische IP-hertoewijzing of hostsleutelconflicten wilt vermijden, speelt de infrastructuur die u kiest een grote rol.
Cloudzy biedt SSH VPS-hosting met speciale statische IP's. Je draait op AMD Ryzen 9-processors met NVMe-opslag voor onmiddellijke uitvoering van opdrachten. Ons netwerk bereikt 40 Gbps op 12 locaties wereldwijd. Bovendien bieden we gratis DDoS-bescherming aan om uw verbinding veilig te houden.
Hoe u de fout ‘Remote Host Identification Has Changed’ kunt oplossen
De oplossing is eenvoudig: verwijder de oude sleutelrecord van uw systeem. Hiermee wordt de discrepantie opgeheven en kunt u de nieuwe sleutel opslaan de volgende keer dat u verbinding maakt. Bekijk onze gids op SSH-klanten voor meer gereedschap.
Bovendien kunt u dit doen met een enkele opdracht of door het bestand handmatig te bewerken.
Methode 1: De opdrachtregel (snelste)
Deze methode werkt voor macOS, Linux en Windows 10+ (met OpenSSH). Het is de snelste manier om de fout op te lossen. Voor meer informatie kunt u de ssh-keygen manpagina.
- Open uw terminal.
- Voer deze opdracht uit (replace hostnaam met het IP-adres of domein van uw 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 u de voorkeur geeft aan een visuele editor, kunt u de sleutel zelf verwijderen. Het foutbericht vertelt u meestal precies welk regelnummer u moet verwijderen.
Open uw terminal en bewerk het bestand met Nano:
nano ~/.ssh/known_hosts
Zoek de regel uit uw foutmelding. Verwijder het en druk vervolgens op Ctrl+X En Y om op te slaan.

Oplossing voor Windows
Windows-gebruikers gebruiken doorgaans de ingebouwde OpenSSH-client of PuTTY.
Optie 1: Windows OpenSSH (Windows 10/11)
Op Windows 10 en 11 is OpenSSH een optionele functie. Voeg het toe via Instellingen > Apps > Optionele functies. Server 2025 bevat de client, maar u moet deze inschakelen.
Als u PowerShell of een opdrachtprompt gebruikt, wordt het ssh-keygen opdracht uit Methode 1 werkt hier ook.
Om het bestand handmatig te bewerken:
- Druk op Windows-toets + R.
- Type %USERPROFILE%\.ssh en druk op Binnenkomen.
- Open de bekende_hosts bestand met Kladblok.
- Verwijder de regel die de fout veroorzaakt en sla het bestand op.
Raadpleeg onze handleiding voor het juiste beheer van sleutels SSH-sleutels genereren 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, typ regedit, en sloeg Binnenkomen).
- Navigeer naar: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Zoek de vermelding die overeenkomt met de hostnaam of het IP-adres van uw server.
- Klik er met de rechtermuisknop op en selecteer Verwijderen.

Oplossing voor Linux
De ssh-keygen opdracht die we hebben behandeld Methode 1 is de standaardmanier om dit op Linux op te lossen. Het is snel en wordt native ondersteund.
Handmatig bewerken
Als u liever de bestandsinhoud ziet, kunt u deze bewerken met een teksteditor zoals Nano.
- Open uw terminal.
- Type nano ~/.ssh/bekende_hosts en druk op Binnenkomen.
- Zoek het regelnummer dat in uw foutmelding wordt vermeld.
- Verwijder de lijn en druk vervolgens op Ctrl+X En Y om op te slaan.
Je kunt ook gebruiken Vim (vim ~/.ssh/known_hosts) als u ermee bekend bent.

Een waarschuwing over het uitschakelen van cheques
Je kunt SSH dwingen om verbinding te maken zonder verificatie, maar dit is riskant. Het omzeilt de bescherming tegen man-in-the-middle-aanvallen.
Gebruik deze aanpak alleen voor lokaal testen op vertrouwde netwerken. Voor macOS en Linux typt u dit:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]
Als u Windows gebruikt, mislukt het Unix-pad. Je moet gebruiken NUL om de bypass te laten werken:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]
Voer deze overschrijvingen niet uit op openbare verbindingen of live servers.
Het oplossen van niet-overeenkomende sleutels is routineonderhoud, maar u kunt meer doen om uw verbinding te beveiligen. Bots richten zich vaak op de standaardpoort 22 met brute-force-aanvallen. U kunt het grootste deel van dit achtergrondgeluid vermijden door SSH-poorten wijzigen in Linux naar iets minder voorspelbaars.

Gebruik deze methode nooit voor productieservers of via niet-vertrouwde netwerken.
Hoe u de volgende keer het bericht 'Remote Host Identification Has Changed' kunt voorkomen
Hoewel u legitieme wijzigingen in de hostsleutel niet altijd kunt voorkomen, kunt u verstoringen tot een minimum beperken en betere beveiligingspraktijken handhaven.
Snelle referentiegids
| Jouw rol | Sleutelstrategieën |
| Systeembeheerders | Maak een back-up van sleutels, documenteer wijzigingen, gebruik certificaten en wissel sleutels regelmatig |
| Regelmatige gebruikers | Houd de inventaris bij, verifieer via beveiligde kanalen en controleer logboeken |
| Cloud-omgeving
Gebruikers |
Gebruik DNS-namen, maak gebruik van providertools en implementeer infrastructuur als code |

Voor systeembeheerders
Back-up maken van hostsleutels: Sleutels opslaan van /etc/ssh/ voordat u het besturingssysteem opnieuw installeert. Herstel ze daarna om waarschuwingen voor uw gebruikers te voorkomen.
Document geplande wijzigingen: Waarschuw gebruikers voordat u sleutels wijzigt en deel de nieuwe vingerafdrukken veilig. Hierdoor kunnen ze de verbinding verifiëren.
Gebruik SSH-certificaten: Grote teams moeten een centrale certificeringsinstantie gebruiken. Hierdoor worden de hostsleutels ondertekend en is handmatige verificatie niet meer nodig.
Sleutelrotatie implementeren: Plan uw hostsleutelwijzigingen. Voorspelbare updates zijn voor uw team gemakkelijker te verwerken dan onverwachte updates.
Voor reguliere gebruikers
Houd een inventaris bij: Houd een persoonlijk register bij van servervingerafdrukken of gebruik de beveiligde documentatie van uw team.
Verifiëren via out-of-band: Bevestig sleutels tegen een vertrouwde bron zoals de cloudconsole, niet tegen informele berichten.
Monitorlogboeken: Controleer uw lokale SSH-logboeken regelmatig op vreemde 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 met behulp van hostnamen in plaats van IP's. Hierdoor blijft de consistentie behouden wanneer het onderliggende adres verandert.
Maak gebruik van cloudtools: Gebruik providerconsoles om huidige vingerafdrukken op te halen. Verifieer sleutels aan de hand van deze tools voordat u wijzigingen accepteert.
Infrastructuur als code: Automatiseer sleutelverificatie met tools zoals Terraform. Voor geavanceerde instellingen kunt u dat ook doen gebruik SSH SOCKS5-proxy's.
Bastion-gastheren: Zet jumpservers op met stabiele sleutels. Deze fungeren als veilige toegangspunten tot uw dynamische infrastructuur.
Conclusie
De “Waarschuwing: Remote Host Identification Has Changed” dient als een belangrijk beveiligingskenmerk van SSH en is geen fout die moet worden genegeerd. Hoewel deze waarschuwing vaak verschijnt om legitieme redenen, zoals serveronderhoud of configuratiewijzigingen, speelt deze een sleutelrol bij het beschermen van u tegen man-in-the-middle-aanvallen en ongeautoriseerde toegang.
Wanneer u deze waarschuwing tegenkomt, controleer dan de oorzaak voordat u doorgaat. In de meeste gevallen is de oplossing eenvoudig: verwijder de oude hostsleutel met behulp van de methoden die voor uw besturingssysteem zijn beschreven en accepteer vervolgens de nieuwe sleutel bij uw volgende verbinding.
Door te leren hoe SSH-hostsleutels werken en de best practices te volgen, kunt u zowel de veiligheid als het gemak van uw externe toegangsworkflows behouden. Voor meer informatie over het veilig overbrengen van bestanden, zie bestanden kopiëren via SSH.