Wanneer je probeert te verbinden met een SSH-server kan het gebeuren dat je een foutmelding krijgt, bijvoorbeeld wanneer de configuratie van je SSH-server afwijkt van de standaard. In deze handleiding bespreken we de meest voorkomende foutmeldingen en leggen we uit hoe je ze kunt verhelpen. 

Permission denied (pubkey, password)

Deze foutmelding komt in twee varianten voor: Permission denied (pubkey) en Permission denied (password). In beide gevallen is authenticatie met een wachtwoord normaal gesproken mogelijk, maar bij de pubkey variant verwacht de server eigenlijk dat een SSH-key gebruikt wordt. 

Hoewel de foutmelding relatief onschuldig is, kan het op zijn tijd nog best lastig zijn om te onderzoeken. Deze foutmelding kent de volgende mogelijke oorzaken: 

• Een incorrecte gebruikersnaam of wachtwoord 
• Een onjuiste SSH-key
• Een onjuiste configuratie van de SSH-server

Een incorrecte gebruikersnaam of wachtwoord

De eenvoudigste manier om de gebruikersnaam en het wachtwoord te controleren, is om te verbinden met je server via de console in het controlepaneel voor VPS, of de console in Horizon voor OpenStack-instances. Je kunt dan direct de gebruikersnaam en het wachtwoord testen waarmee je via SSH probeert te verbinden, of bijvoorbeeld met de root-gebruiker inloggen en dan overschakelen naar de gebruiker met het commando:

su <gebruikersnaam>

Vervang <gebruikersnaam> door de naam van de gebruiker. Krijg je een melding dat het wachtwoord niet klopt? Log dan in met de root-gebruiker of een andere gebruiker met sudo-rechten en reset het wachtwoord met het commando:

passwd <gebruikersnaam>

Een onjuiste SSH-key

Maak je gebruik van SSH-keys en krijg je de ‘Permission denied (pubkey)’- foutmelding? Controleer dan of je op de juiste manier je SSH-key hebt gegenereerd en de public key correct hebt toegevoegd aan je VPS. Je kunt hiervoor gebruik maken van onze handleiding 'SSH-keys genereren en gebruiken’.

Wil je echter met een wachtwoord inloggen via SSH en krijg je deze foutmelding? Doorloop dan de stappen in de paragraven ‘Een incorrecte gebruikersnaam of wachtwoord’ en ‘Een onjuiste configuratie van de SSH-server’.

Een onjuiste configuratie van de SSH-server

Gebruik je de juiste gebruikersnaam en wachtwoord maar krijg je alsnog de Permission denied foutmelding? Dan wordt dat waarschijnlijk veroorzaakt door de configuratie van je SSH-server. De eenvoudigste manier om configuratieproblemen uit te sluiten is de configuratie te herstellen naar de standaardwaardes.

Stap 1

Verbind met je server via de console in het controlepaneel voor VPS, of de console in Horizon voor OpenStack-instances.

Stap 2

Open de SSH-configuratie als root-gebruiker, of met sudo:

sudo nano /etc/ssh/sshd_config

Stap 3

De meeste regels zijn standaard uitgecommentarieerd. Krijg je een 'Permission Denied'-foutmelding en wijkt jouw configuratie af van de configuratie hieronder? Plaats dan een # voor alle regels die niet hieronder staan bij het besturingssystemen dat jij gebruikt. Sla daarna je wijzigingen op en sluit de configuratie (ctrl + x > y > enter).

AlmaLinux/Rocky Linux/CentOS Stream:

Include /etc/ssh/sshd_config.d/*.conf
AuthorizedKeysFile      .ssh/authorized_keys
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Ubuntu:

Include /etc/ssh/sshd_config.d/*.conf
KbdInteractiveAuthentication no
UsePAM yes
X11Forwarding yes
PrimtMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server

Debian:

Include /etc/ssh/sshd_config.d/*.conf
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrimtMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server

Stap 4

Herlaad de SSH-configuratie tot slot:

sudo systemctl reload sshd

Probeer nu nogmaals te verbinden met je SSH-server.

Host Key Verification Failed Error Message: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Een foutmelding die erop wijst dat de host key van de server waar je mee probeert te verbinden is veranderd. Normaal gesproken zie je deze foutmelding na de herinstallatie van je server: jouw computer heeft dan namelijk nog de oude host key opgeslagen terwijl die na de herinstallatie is veranderd. Het is zeldzaam en relatief onwaarschijnlijk dat je deze melding krijgt omdat er iets ernstigers aan de hand is (bijvorbeeld als de server is gecompromitteerd). 

Windows

Wanneer je gebruik maakt van Windows i.c.m. Putty om de SSH-verbinding te maken, kun je simpelweg accepteren dat er een andere host key wordt aangeboden: jouw computer slaat die dan vervolgens op en je krijgt de melding niet nogmaals te zien.

Linux

Verbind je vanaf een Linux-distro? Dan kun je de oude host key verwijderen. Deze zijn opgenomen in de ~/.ssh/known_hosts directory en een specifieke host key verwijder je bijvoorbeeld met het commando:

ssh-keygen -R <hostname>

Vervang hier <hostname> door de hostname waar je via SSH mee probeert te verbinden. 

SSH: Connect to host <hostname> port 22: Network is unreachable

Je computer/laptop slaagt er niet in om een verbinding te maken met de SSH-server op Deze foutmelding kan het gevolg zijn van:

• De SSH-server is offline/Er is geen SSH-server actief
• De SSH-server maakt gebruik van een andere poort
• Een firewall blokkeert de verbinding
• Selinux blokkeert de verbinding
• Je gebruikt een VPN-verbinding

De SSH-server is offline/Er is geen SSH-server actief

Het ligt misschien voor de hand, maar het is mogelijk dat je SSH-server niet actief is omdat die niet gestart is, of gecrsahed is. Dit sluit je uit door te verbinden met je server via de console in het controlepaneel voor VPS, of de console in Horizon voor OpenStack-instances. Gebruik hiervoor de root-gebruiker, of een gebruiker met sudo-rechten. Voer vervolgens het volgende commando uit:

sudo systemctl status sshd | grep Active:

Zie je in de output "Active: active (running)"? Dan is jouw SSH-server actief en speelt er mogelijk een ander probleem.

Wanneer je hier een andere status te zien krijgt kun je eerst proberen de SSH-server te herstarten met het commando:

sudo systemctl restart sshd

Krijg je nu een foutmelding? Controleer dan je logbestanden en onderzoek de specifieke foutmelding:

journalctl -xe -u sshd

De SSH-server maakt gebruik van een andere poort

We moedigen aan om de SSH-poort van jouw server te veranderen. Het is belangrijk dat, wanneer je dat doet, je daar rekening mee houdt bij het verbinden met je server. 

Je kunt controleren of dit het geval is door te verbinden met je server via de console in het controlepaneel voor je VPS, of de console in Horizon voor OpenStack-instances als root-gebruiker, of een gebruiker met sudo-rechten. Voer vervolgens het volgende commando uit:

sudo cat /etc/ssh/sshd_config | grep Port

In de output krijg je te zien op welk poortnummer SSH actief is. Verbind je al met jouw SSH-server op dit poortnummer? Dan speelt er mogelijk een andere oorzaak waardoor je niet kunt verbinden met jouw VPS.

Let wel dat het belangrijk is dat als je een andere poort voor SSH gebruikt je deze ook open zet in je firewall, zie de volgende paragraaf.

Een firewall blokkeert de verbinding

Wanneer je zeker weet dat je SSH-server online is én van welke poort die gebruik maakt, is het goed mogelijk dat de poort door een firewall of door SeLinux geblokkeerd wordt. 

De VPS-firewall in het TransIP-controlaneel

Controleer of de VPS-firewall in het TransIP-controlepaneel is ingeschakeld en zo ja, of die de correcte SSH-poort toestaat (zie de vorige paragraaf). 

De firewall op je VPS

Stap 1

Voor je controleert of de firewall op je VPS de SSH-poort blokkeert, is het handig om te controleren welke poort voor SSH gebruikt wordt. Verbind met je server via de console in het controlepaneel voor je VPS, of de console in Horizon voor OpenStack-instances als root-gebruiker, of een gebruiker met sudo-rechten. Voer vervolgens het volgende commando uit:

sudo cat /etc/ssh/sshd_config | grep Port

Noteer/onthoud het poortnummer dat je hier terugziet.

Stap 2

Open de poort in je firewall (vervang 22 door het daadwerkelijke poortnummer). Staat de poort al open? Dan krijg je daarvan een melding van en is dit waarschijnlijk niet de oorzaak van je verbindingsproblemen.

AlmaLinux/Rocky Linux/CentOS Stream:

sudo firewall-cmd --permanent --zone=public --remove-port=22/tcp 
sudo firewall-cmd --reload

Ubuntu/Debian:

 ufw allow 22

Selinux blokeert de verbinding

Security-Enhanced Linux, of SELinux, is een kernel security module die doorgaans in Red Hat systemen zoals AlmaLinux, Rocky Linux en CentOS Stream gebruikt wordt. Selinux controleert poorttoegang, enigszins vergelijkbaar met een firewall in dat opzicht. Om uit te sluiten of Selinux je SSH-verbinding blokkeert, doorloop je de stappen hieronder.

Stap 1

Verbind met je server via de console in het controlepaneel voor je VPS, of de console in Horizon voor OpenStack-instances als root-gebruiker, of een gebruiker met sudo-rechten. 

Stap 2

Voer het volgende commando uit:

sestatus

De output ziet er als volgt uit:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

Staat de status op 'enabled' en de mode op ‘enforcing’ (en niet bijvoorbeeld dismissive)? Dan is Selinux ingeschakeld en actief. Zo niet, dan blokkeert Selinux niet jouw SSH-poort en kun je een andere oplossing proberen.

Stap 3

Controleer of de SSH-poort open staat met het commando:

semanage port -l | grep poortnummer

Vervang hier 'poortnummer' door het nummer van de poort die je daadwerkelijk wil controleren.

Je kunt alternatief ook direct op poort-type (i.e. een specifiek programma/service) controleren met het commando:

semanage port -l | grep -w ssh_port_t

Staat de SSH-poort dicht? dan kun je die in Selinux openen met het commando:

semanage port --add -t ssh_port_t -p tcp 22

Vervang eventueel 22 door het nummer van je SSH-poort indien je die aangepast hebt. 

Je gebruikt een VPN-verbinding

Als je een VPN-verbinding gebruikt, kan het gebeuren dat je de ‘Network is unreachable’- of ‘Connection timed out’-foutmelding krijgt. Dit gebeurt meestal omdat je firewall danwel alleen het IP-adres van je VPN-verbinding toestaat, of die misschien niet gewhitelist is in je firewall.

Controleer in dit geval of je VPN-verbinding uit-of aan staat en of een eventuele firewall de verbinding blokkeert, zie de eerdere paragraaf over firewalls bij SSH-verbindingsproblemen.

ssh: connect to host [hostname] port 22: Connection timed out

Deze foutmelding is doorgaans een indicatie dat de SSH-server niet bereikt kan worden. In dit geval kan het goed zijn dat de oorzaak ligt bij de computer waarmee je probeert te verbinden met de SSH-server. De meest voorkomende oorzaken van deze foutmelding zijn:

• Een DNS-probleem
• Een netwerk-issue
• Een firewall blokkeert de verbinding (al dan niet in combinatie met een VPN)
• De SSH-server is niet actief

Een DNS-probleem

Wanneer er een DNS-probleem speelt en je probeert te verbinden met de hostname van je SSH-server (bijv. server.voorbeeld.nl) krijgt je computer die hostname niet gevonden. In dat geval is het een goed idee te proberen te verbinden met het IP-adres van de SSH-server, bijvoorbeeld voor Linux-distros met het commando:

ssh <gebruikersnaam>@123.123.123.123 

Vervang hier <gebruikersnaam> door de naam van de SSH-gebruiker en 123.123.123.123 door het IP-adres van de SSH-server.

Kun je nu wel een verbinding maken met je SSH-server? Dan speelt er een DNS-probleem. Voer eerst een traceroute/MTR uit om uit te sluiten of er een verbindingsprobleem is, controleer vervolgens de hostname van je SSH-server en controleer tot slot of de DNS-instellingen van het domein correct naar je SSH-server verwijzen.

Een netwerk-issue

Het is mogelijk dat het probleem zich bevindt tussen jouw computer en de SSH-server, bijvoorbeeld bij een router tussen jouw computer en de SSH-server: naast je router thuis en in het datacenter waar jouw SSH-server staat, worden  doorgaans nog aanvullende verbindingen gemaakt via andere netwerken. Om te kijken of er in dit hele traject een netwerk-issue speelt, raden we aan een traceroute/MTR uit te voeren om te kijken of daar sprake van is. 

In het geval je router thuis een probleem ervaart, is meestal een herstart of een reset (dat zijn twee verschillende handelingen) voldoende om het probleem te verhelpen.

ssh: connect to host [hostname] port 22: No route to host 

Een vrij veel voorkomende foutmelding waarbij de oorzaak in veel gevallen onderzocht moet worden op de SSH-server. De meest voorkomende oorzaken zijn:

• De SSH-server is down/heeft geen internetverbinding
• Een netwerk-issue tussen jouw computer en de SSH-server
• Een firewall blokkeert de verbinding (hoewel dit ook vaak de Network is unreachable foutmelding geeft)

De SSH-server is down/heeft geen internetverbinding

Om deze oorzaak uit te sluiten, verbind je met je server via de console in het controlepaneel voor je VPS, of de console in Horizon voor OpenStack-instances als root-gebruiker, of een gebruiker met sudo-rechten. Kun je inloggen op je SSH-server? Voer dan een ping opdracht uit naar het IP-adres 8.8.8.8:

ping 8.8.8.8

Slaagt het pingcommando? Dan is je netwerkverbinding in orde. Controleer vervolgens ook de status van je SSH-server.

ssh: connect to host [hostname] port 22: Connection refused

Bij deze foutmelding bereikt jouw computer wel de SSH-server, maar stuurt de server een TCP ‘reset’ package terug omdat de SSH-service niet actief is of van een andere poort gebruik maakt. In de volgende onderdelen leggen we uit hoe je dit onderzoekt:

• De SSH-service is niet actief
• De SSH-service gebruikt een andere poort

Permissions 0644 for 'id_rsa' are too open

Deze foutmelding geeft aan dat de private key file te brede permissies heeft. Deze foutmelding verhelp je door als root-gebruiker, of een gebruiker met sudo-rechten de permissies voor id_rsa aan te passen met het commando:

chmod 600 ~/.ssh/id_rsa

Daarmee zijn we aan het eind gekomen van deze handleiding over het onderzoeken van SSH-verbindingsproblemen. Kom je een andere foutmelding tegen waar je graag uitleg bij wil of vind je een oplossing die niet in dit artikel genoemd is? Dan horen we graag van je via de ‘Neem contact op’-knop onderaan dit artikel.