50% korting alle plannen, beperkte tijd. Vanaf $2.48/mo
Nog 10 min
Beveiliging en netwerk

Waarschuwing: Remote Host Identification is gewijzigd en hoe je dit oplost

Rexa Cyrus By Rexa Cyrus 10 min leestijd 56d geleden bijgewerkt
Terminalvenster met SSH-waarschuwing over wijziging van remote host identification, met titel Fix Guide en Cloudzy-branding op donkere teal achtergrond.

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.

Infographic die serverwijzigingen toont die de SSH-hostsleutels wijzigen, inclusief OS-upgrades, het opnieuw opbouwen van de server, het herstellen van back-ups, fysieke naar virtuele migratie 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 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

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

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


Gesplitst scherm waarin legitieme SSH-wijzigingen, weergegeven in het groen, worden vergeleken met scenario's voor beveiligingsbedreigingen in het rood, met een figuur met een kap die man-in-the-middle-aanvallen voorstelt.
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:

Stroomdiagram met vijf verificatiemethoden voor het bevestigen van legitieme SSH-hostsleutelwijzigingen, inclusief teamoverleg, contact met hostingprovider, beveiligde kanalen en vergelijking van vingerafdrukken.

  1. Neem contact op met uw team: Als u de servertoegang deelt, vraag dan aan collega's of zij wijzigingen hebben aangebracht
  2. Serverlogboeken bekijken: Controleer onderhoudsgegevens of wijzig logboeken voor recente activiteiten
  3. Neem contact op met uw hostingprovider: Als u cloudservices gebruikt, controleer dan of er onderhoud heeft plaatsgevonden
  4. Gebruik een beveiligd kanaal: Maak indien mogelijk verbinding via een bekend beveiligd netwerk om de vingerafdruk te verifiëren
  5. 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

  1. Open uw terminal.
  2. 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.

macOS-terminalvenster waarin de nano-teksteditor geopend is met het bestandknown_hosts, waarbij de regel wordt gemarkeerd die moet worden verwijderd met genummerde stappen en instructies voor het opslaan.

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:

  1. Druk op Windows-toets + R.
  2. Type %USERPROFILE%\.ssh en druk op Binnenkomen.
  3. Open de bekende_hosts bestand met Kladblok.
  4. 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.

  1. Open de Register-editor (druk op Windows-toets + R, typ regedit, en sloeg Binnenkomen).
  2. Navigeer naar: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
  3. Zoek de vermelding die overeenkomt met de hostnaam of het IP-adres van uw server.
  4. Klik er met de rechtermuisknop op en selecteer Verwijderen.

Windows PowerShell-opdracht waarbij de SSH-hostsleutel wordt verwijderd, waarbij de Verkenner het bijgewerkte bestandknown_hosts toont en de PuTTY Register-editor het bevestigingsvenster voor het verwijderen van de hostsleutel weergeeft.

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.

  1. Open uw terminal.
  2. Type nano ~/.ssh/bekende_hosts en druk op Binnenkomen.
  3. Zoek het regelnummer dat in uw foutmelding wordt vermeld.
  4. 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.

Linux-terminal met ssh-keygen-opdrachten om SSH-hostsleutels te verwijderen op basis van hostnaam en IP-adres, met succesbevestiging en bekende_hosts-bestandsvoorbeelden.
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.

Diagram van een man-in-the-middle-aanval op SSH: aanvaller onderschept client-server-verbinding, sleutel van aanvaller versus serversleutel, gegevensdiefstal en financieel verlies benadrukt.

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

Infographic met best practices voor SSH-sleutelbeheer: gebruik SSH-certificaten, DNS-namen, infrastructuur als code, maak back-ups van hostsleutels, documenteer wijzigingen en overweeg bastionhosts.

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.

 

Veelgestelde vragen

Moet ik de waarschuwing ter harte nemen: de identificatie van externe hosts is ernstig veranderd?

Ja, neem het serieus. Het betekent dat de identiteit van de server is veranderd, wat kan duiden op een man-in-the-middle-aanval of gewoon routineonderhoud. Verifieer altijd de wijziging bij uw beheerder of provider voordat u de nieuwe sleutel accepteert, om de veiligheid te garanderen.

Wat veroorzaakt de waarschuwing: de identificatie van de externe host is veranderd?

Deze waarschuwing verschijnt wanneer de huidige vingerafdruk van de server niet overeenkomt met die in uw bestandknown_hosts. Veelvoorkomende oorzaken zijn onder meer herinstallaties van het besturingssysteem, nieuwe IP-toewijzingen of resets van de SSH-configuratie. In zeldzame gevallen duidt dit op een actieve onderschepping van een man-in-the-middle-aanval.

Kan deze fout optreden op verschillende besturingssystemen?

Ja, deze waarschuwing is van invloed op alle besturingssystemen die SSH gebruiken, inclusief Windows, macOS en Linux. Het komt voort uit de beveiligingsverificatie van het SSH-protocol. Hoewel de herstelmethoden per platform verschillen, blijft de onderliggende beveiligingstrigger op elk systeem identiek.

Hoe weet ik of de wijziging van de hostsleutel legitiem is of een aanval?

Om de legitimiteit te bevestigen, controleert u op recent onderhoud, OS-updates of IP-wijzigingen. U moet de nieuwe vingerafdruk verifiëren aan de hand van een vertrouwde bron, zoals de console van uw cloudprovider of een bevestiging van uw systeembeheerder, voordat u verbinding maakt.

Zal het uitschakelen van de hostsleutelcontrole SSH handiger maken?

Het voegt gemak toe, maar neemt de veiligheid weg. Als u controles uitschakelt, wordt de bescherming tegen man-in-the-middle-aanvallen uitgeschakeld, waardoor verbindingen kwetsbaar blijven. 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 vereisen over het algemeen geen regelmatige rotatie. Normaal gesproken moet u deze alleen wijzigen nadat de server opnieuw is opgebouwd, het besturingssysteem opnieuw is geïnstalleerd of de beveiliging in gevaar is gebracht. Frequente veranderingen verstoren gebruikers, dus geef prioriteit aan stabiliteit en duidelijke communicatie wanneer updates nodig zijn.

Deel

Meer van de blog

Blijf lezen.

Een Cloudzy-titelafbeelding voor een MikroTik L2TP VPN-gids, met een laptop die via een gloeiende blauwgouden digitale tunnel met schildiconen verbonden is met een serverrek.
Beveiliging en netwerk

MikroTik L2TP VPN-setup (met IPsec): RouterOS-gids (2026)

In deze MikroTik L2TP VPN-setup verzorgt L2TP de tunneling en IPsec de versleuteling en integriteit. De combinatie geeft je native clientcompatibiliteit zonder third-party age

Rexa CyrusRexa Cyrus 9 min leestijd
Illustratie van een DNS-server-troubleshootinggids met waarschuwingssymbolen en een blauwe server op donkere achtergrond, voor Linux-naamresolutiefouten
Beveiliging en netwerk

Temporary Failure in Name Resolution: wat betekent het en hoe los je het op?

Bij het gebruik van Linux kun je een 'temporary failure in name resolution'-fout tegenkomen bij het bezoeken van websites, het updaten van pakketten of het uitvoeren van taken die internetverbi

Rexa CyrusRexa Cyrus 12 min leestijd
Hoe u een domein naar een VPS kunt verwijzen: een korte handleiding
Beveiliging en netwerk

Hoe u een domein naar een VPS kunt verwijzen: een korte handleiding

Het verwijzen van een domein naar een Virtual Private Server is noodzakelijk voor het hosten van websites en applicaties. In deze handleiding vindt u alles wat u moet weten over het koppelen van uw domein aan uw

Rexa CyrusRexa Cyrus 16 min leestijd

Klaar om uit te rollen? Vanaf $2,48/mnd.

Onafhankelijke cloud, sinds 2008. AMD EPYC, NVMe, 40 Gbps. 14 dagen niet-goed-geld-terug.