De “Authenticity of host can’t be established” fout treedt meestal op wanneer je voor het eerst probeert via SSH (Secure Shell) verbinding te maken met een server. Het kan echter ook wijzen op een ernstig probleem. Iemand kan zich bijvoorbeeld voordoen als de identiteit van de server.

Gelukkig zijn er verschillende manieren om de fout “Authenticity of host can’t be established” op te lossen en te zorgen voor een soepele en veilige verbinding. Het kan bijvoorbeeld nodig zijn om een zelfbeheerde Certificate Authority (CA) aan te maken, je SSH software te upgraden, of de host op afstand te verifiëren.

In dit artikel gaan we dieper in op de fout “Authenticity of host can’t be established”. Daarna doorlopen we enkele veel voorkomende oorzaken en bespreken we acht eenvoudige oplossingen. Laten we beginnen!

Wat is de “Authenticity of host can’t be established” fout?

“Authenticity of host can’t be established” is een veel voorkomende fout die vooral optreedt bij het gebruik van SSH (Secure Shell). Meestal moet je de SSH verbinding authenticeren met een wachtwoord.

Je kunt echter ook authenticeren met public key cryptografie. Hierbij wordt een SSH sleutelpaar gegenereerd dat bestaat uit een publieke en private sleutel. De private sleutel blijft op je eigen systeem, terwijl de publieke sleutel wordt gekopieerd naar het systeem waarmee je verbinding maakt.

Meestal krijg je deze foutmelding de eerste keer dat je via SSH verbinding maakt met de server. Dit komt omdat de SSH client niet bekend is met de server.

Als je de server vertrouwt, kun je de foutmelding negeren. Deze actie zal de SSH sleutel in je known_hosts bestand zetten. Vervolgens kun je elke keer dat je verbinding maakt de sleutel die je van de host krijgt vergelijken met die in je known_hosts bestand om de identiteit van de server te verifiëren.

Als je eerder met de server hebt verbonden, suggereert de fout “Authenticity of host can’t be established” dat de server opnieuw is geconfigureerd met een nieuwe sleutel. Deze melding kan echter ook op een probleem duiden.

Het kan bijvoorbeeld het geval zijn dat iemand zich voordoet als de identiteit van de server en alle gegevens kan onderscheppen die via de verbinding worden verstuurd. We zullen de belangrijkste oorzaken nader bekijken in de volgende paragraaf.

Wat veroorzaakt de “Authenticity of host can’t be establishedd” fout?

Er zijn meerdere oorzaken voor de “Authenticity of host can’t be established” fout. Hier zijn enkele van de meest voorkomende:

  • De publieke sleutel van de remote host is veranderd. Hoewel dit meestal betekent dat de server is bijgewerkt, kan het er ook op wijzen dat de host gehackt is. In dit geval zou een aanvaller kunnen proberen zich voor te doen als de host.
  • De cliënt heeft nog niet eerder verbinding gemaakt met de remote host. Als dit het geval is, is de SSH niet bekend met de server en kan daarom een foutmelding geven.
  • Meerdere hostsleutels. Een server kan meerdere hostsleutels hebben, zoals ECDSA en RSA. Als je de verkeerde sleutel gebruikt, kun je de foutmelding krijgen.
  • De sleutel van de host is verwijderd of beschadigd. In dit geval ontstaat een SSHException, die de fout “Authenticity of host can’t be established” oplevert.
  • Het DNS van de remote host is verkeerd geconfigureerd. Een verkeerd geconfigureerd Domain Name System (DNS) kan je verbinden met een host met een onjuiste hostsleutel.
  • Een man-in-the-middle aanval. De fout kan een teken zijn dat een aanvaller de verbinding tussen jou en de andere host onderschept.

Voor betere beveiliging en prestaties is het belangrijk dat je een hostingdienst van goede kwaliteit kiest. Met Kinsta’s Applicatie Hosting kun je je projecten draaien op de infrastructuur van Google Cloud Platforms:

Kinsta’s application hosting service
Kinsta’s Applicatie Hosting dienst

Bovendien wordt het platform ondersteund door Cloudflare’s zakelijke beveiligingsoplossingen. Hieronder valt een firewall en DDoS bescherming.

Bovendien heb je toegang tot gratis SSL certificaten of kun je custom certificaten installeren. Ondertussen is het dankzij ons prijsmodel op basis van gebruik gemakkelijk om je resources te schalen naarmate je bedrijf groeit.

Zo los je de “Authenticity of host can’t be established” fout op (8 methoden)

Nu je wat meer weet over de “Authenticity of host can’t be established” fout, laten we eens kijken naar acht manieren om het op te lossen.

1. Controleer je verbinding

De eerste manier om de “Authenticity of host can’t be established” fout op te lossen is door ervoor te zorgen dat de netwerkverbinding stabiel is. Daarnaast is het een goed idee om te controleren of er niets is dat de verbinding blokkeert.

Het kan zijn dat er een antivirusprogramma draait of een Web Application Firewall (WAF) geactiveerd is. Dit kan de verbinding verstoren, dus misschien wil je de software tijdelijk uitschakelen om te proberen de foutmelding op te heffen.

2. Vervang het IP adres

Veel mensen nemen ten onrechte aan dat elke remote server maar één sleutel heeft, terwijl een server in feite meerdere hostsleutels kan hebben. Dus jij gebruikt misschien de RSA hostsleutel, maar de server geeft je een ECDSA hostsleutel.

Het kan dus zijn dat je een foutmelding krijgt omdat de hostsleutel anders is. Als je de HostKeyAlgorithms optie expliciet hebt ingesteld, zal SSH deze in acht nemen en de voorkeur geven aan de algoritmen die je hebt opgegeven.

Je kunt in je bestanden ~/.ssh/config en /etc/ssh/ssh_config kijken of dat het geval is. Zo ja, voeg dan een regel toe aan je ~/.ssh/config bestand zoals deze:

# Update with the real IP address. Host 192.0.2.1 HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-rsa

Het is belangrijk op te merken dat dit het gebruik van SHA-1 signatures mogelijk maakt. SHA-1 signatures worden niet langer als veilig beschouwd omdat er kwetsbaarheden rond zijn. Daarom kun je, als je weet dat de server SHA-2 signatures ondersteunt, het commando verwijderen.

Het kan ook zijn dat het systeem geen gehashte invoer gebruikt. Daarom is de vermelding die je expliciet hebt toegevoegd misschien niet correct.

In dit scenario moet je dezelfde configuratiebestanden controleren op HashKnownHosts en de vermelding dienovereenkomstig aanpassen. Je kunt ook ssh-keygen -F 192.0.2.1 -l (ter vervanging van het IP adres) gebruiken om te zien of er een match is voor de entry.

3. Sla de hostsleutel check over

Er zijn gevallen waarin de foutmelding “Authenticity of host can’t be established” onschuldig is. De hostsleutel kan bijvoorbeeld op een legitieme manier veranderd zijn als de server onlangs is bijgewerkt of opnieuw geconfigureerd.

Als dit het geval is, kun je de sleutelcontroleprocedure overslaan door de sleutel naar een null known_hosts bestand te sturen. In dit bestand moet je de volgende regel toevoegen:

$ ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" user@host

Je kunt deze opties ook permanent instellen in ~/.ssh/config (voor de huidige gebruiker). Als je het voor alle gebruikers wilt instellen, gebruik dan /etc/ssh/ssh_config.

4. Maak je eigen zelfbeheerde Certificate Authority (CA)

Webbrowsers hebben X509 rootcertificaten voorgeïnstalleerd, waarmee je de Secure Sockets Layer (SSL) certificaten van sites die je nog nooit hebt bezocht kunt vertrouwen. Sommige SSH clients ondersteunen X509 of PKI, maar andere niet. Dit betekent dat je een SSL certificaat van VeriSign niet kunt gebruiken om de authenticiteitsprompt te omzeilen als de client dat niet ondersteunt.

Je zou echter de fout “Authenticity of host can’t be established” kunnen opheffen door je eigen zelfbeheerde Certificate Authority (CA) aan te maken, want dan kun je inloggen op de server. Bovendien zal elke client met jouw publieke sleutel automatisch jouw servers vertrouwen.

Om te beginnen moet je een SSH sleutelpaar aanmaken. Je kunt dit doen met het volgende item:

ssh-keygen -f cert_signer

Vervolgens kun je de openbare hostsleutel van elke server als zodanig ondertekenen:

ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Dit genereert een ondertekende openbare hostsleutel:

/etc/ssh/ssh_host_rsa_key-cert.pub

Navigeer nu naar je /etc/ssh/sshd_config bestand. Hier kun je het HostCertificate naar dit bestand verwijzen: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub.

Start vervolgens de SSH dienst opnieuw op. Op de SSH client moet je de volgende code toevoegen aan het known_hosts bestand:

@cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Deze vermelding omvat:

  • De certificaatautoriteit
  • Het domein (example.com)
  • De volledige inhoud van de openbare sleutel

De fout zou nu moeten verdwijnen, omdat de cert_signer publieke sleutel elke server zal vertrouwen waarvan de publieke hostsleutel is ondertekend door de cert_signer private sleutel.

5. Werk de SSH software bij

Een andere oplossing voor de fout “Authenticity of host can’t be established” is het upgraden van je SSH clientsoftware om er zeker van te zijn dat je de laatste versie gebruikt. Zo weet je zeker dat je software compatibel is met de remote host.

Updates bevatten vaak bugfixes en beveiligingspatches die de stabiliteit en veiligheid van de verbinding verbeteren. Als je de software hebt bijgewerkt, zou je verder moeten kunnen gaan zonder de foutmelding te zien.

6. Controleer de remote host

Je kunt ook de foutmelding “Authenticity of host can’t be established” krijgen als de hostsleutel onjuist of verlopen is. Daarom zou je kunnen controleren of de sleutel van de remote host correct is gegenereerd en nog steeds geldig is.

Door dit te doen kun je controleren of de externe server online is en beschikbaar voor verbindingen. Ondertussen kun je ervoor zorgen dat de hostsleutel correct is. Op deze manier kun je bevestigen dat je verbinding maakt met de juiste server (en niet met een kwaadaardige server die zich voordoet als de doelserver).

Om te beginnen controleer je de remote host met het commando “ssh-keyscan”:

ssh-keyscan example.com

Hiermee wordt de publieke sleutel van de remote host opgehaald en op je terminal getoond. Vervolgens kun je deze sleutel vergelijken met de sleutel in je known_hosts bestand (of met de sleutel van de beheerder van de server).

Als de sleutels overeenkomen, is de remote host waarschijnlijk de juiste server. Als de sleutels echter niet overeenkomen, kun je het beste het probleem melden aan de serverbeheerder en de verbinding stopzetten.

7. Verwijder de oude hostsleutel

De fout “Authenticity of host can’t be established” kan ook betekenen dat je hostsleutel is veranderd. Daarom kun je de fout misschien oplossen door de oude sleutel uit je known_hosts bestand te verwijderen.

De sleutel van de externe server kan zijn bijgewerkt vanwege een wijziging in de configuratie van de server of een beveiligingslek. In dit geval zal de oude hostsleutel niet overeenkomen met de nieuwe, en een fout veroorzaken.

Het enige wat je moet doen is de entry voor de publieke sleutel van de remote host die is opgeslagen in known_hosts verwijderen. Gebruik hiervoor het volgende commando:

ssh-keygen -R example.com

Dit zal de vermelding uit het known_hosts bestand verwijderen. De volgende keer dat je via SSH verbinding probeert te maken met de server, moet je de nieuwe hostsleutel verifiëren.

8. Flush je DNS

Tenslotte kan het zijn dat het Domain Name System (DNS) van je host verkeerd geconfigureerd is. Dit kan leiden tot verbinding met een host met de verkeerde sleutel, wat resulteert in de “Authenticity of host can’t be established” fout.

De eenvoudigste manier om dit probleem op te lossen is door je DNS te flushen. Open hiervoor de Windows Opdrachtprompt door “cmd” in de zoekbalk te typen:

Opdrachtprompt in Windows
Opdrachtprompt in Windows

Voer dan het volgende SSH commando in:

ipconfig/flushdns

Dit zou de fout moeten opheffen en je in staat moeten stellen verbinding te maken met de server.

Samenvatting

De “Authenticity of host can’t be established” fout treedt meestal op wanneer je probeert via SSH verbinding te maken met een server. Het kan erop wijzen dat de server opnieuw geconfigureerd is. Het kan echter ook betekenen dat de server gehackt is.

Als het de eerste keer is dat je verbinding maakt, is het normaal om deze foutmelding te zien en kun je hem gewoon negeren. Zo niet, dan moet je misschien de host verifiëren om er zeker van te zijn dat je verbinding maakt met de juiste server. Misschien moet je ook de oude host verwijderen uit het known_hosts bestand of je SSH software upgraden.

Een andere eenvoudige manier om de beveiliging van je applicatie te verhogen is het gebruik van een high-quality host zoals Kinsta. Al onze pakketten bieden ondersteuning van topkwaliteit om eventuele problemen op te lossen!