SSH-problemen oplossen zonder je toegang te verliezen

Leg één mislukte poging vast

Clientcommando’s voer je op je computer uit in Linux, macOS of WSL. Servercommando’s horen in bestaande toegang of een vertrouwde herstelconsole. Vervang documentatieadres, ubuntu, poort 22 en sleutelpad door je werkelijke gegevens.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Bekijk hostname, user, port, identityfile en proxy-instellingen. De tweede poging gebruikt geen gedeelde verbinding. Noteer tijd en laatste fout; verifieer een nieuwe hostsleutel via de procedure hieronder. Scherm namen, adressen en paden af bij delen van debuguitvoer. Deel nooit een privésleutel.

Kies de juiste foutcategorie

Schuif de tabel opzij om alle kolommen te bekijken.

Dit zijn aanwijzingen, geen definitieve oorzaken. Staat Connection established al vóór een time-out, kijk dan naar handshake en serverlogs in plaats van alleen pakketblokkades.

Time-out: volg de netwerkroute

Vergelijk het doeladres van ssh -v met het providerpaneel. Oude DNS of een ander IPv6-adres kan elders uitkomen. Heeft de VPS een publiek adres, VPN of jump host nodig? Controleer Running, publieke route, echte doelpoort en huidige publieke bron-IP. Een /32-regel kan verouderen na een adreswijziging.

Controleer via de console ook de gastfirewall. Bij Oracle tellen routes, security lists en NSG’s mee. Behoud bestaande imageregels: UFW installeren of iptables leegmaken is geen diagnose. De Oracle-handleiding beschrijft de route. Mislukte ping bewijst op zichzelf geen mislukte SSH.

Geweigerd: inspecteer de luisterende service

Een weigering bewijst niet dat dit de bedoelde machine is. Controleer identiteit en poort, en voer op de server via bestaande toegang of console uit:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Zoek de juiste listener en vergelijk logtijden met je poging. Ubuntu kan socketactivatie gebruiken: een inactieve ssh.service is geen bewijs van onbereikbaarheid als ssh.socket luistert.

sshd -t controleert configuratie en hostsleutels zonder de daemon te starten. Stil succes bewijst geen netwerktoegang. Los een gemelde fout eerst op; herstart niet blind.

Publickey-fout: controleer gebruiker en aangeboden sleutel

Gebruik de juiste eerste gebruiker of zelf aangemaakte beheerder. Bekijk in clientdebug welke vingerafdruk wordt aangeboden. Verminder ongewenste agentkeys lokaal met:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentityFile-instellingen kunnen blijven gelden; lees ssh -G. Los een onleesbare of te ruim toegankelijke privésleutel lokaal op voordat je de server wijzigt.

Inspecteer op de server de doelaccount en toegestane publieke sleutels. Vervang /home/ubuntu door het pad dat getent werkelijk geeft.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Vergelijk vingerafdrukken en bekijk logs voor eigendom, rechten en accountbeleid. Houd rekening met AuthorizedKeysFile, Include-snippets, Match-regels en sleutelbeheer door de provider. Bewaar bestaande sleutels; schakel StrictModes niet uit en zet geen wachtwoorden aan om de oorzaak te verbergen.

Andere hostsleutel: verifieer eerst

Een rebuild of herverdeeld IP kan een sleutel veranderen, maar ook een verkeerde bestemming of onderschepping is mogelijk. Controleer instance-ID en geplande wijzigingen in je aangemelde providerpaneel.

Controleer via vertrouwde toegang tot de gast de publieke hostsleutel met hetzelfde algoritme als de client. Voor Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Vergelijk SHA256. Dit is niet je inlogsleutel of de sleutel van de consolegateway. Werk na bewezen vervanging alleen de betreffende opgeslagen host bij, met back-up van het bestand. Verwijder niet heel known_hosts en omzeil de controle niet. Stop als de afwijking onverklaard blijft.

Test de gerichte correctie opnieuw

Herstel alleen de aangetoonde fout: adres, gebruiker, sleutel, beperkte netwerkregel of configuratie. Houd onafhankelijke toegang beschikbaar en valideer SSH-configuratie vóór toepassen. Een andere poort kan ook socketinstellingen vereisen.

Herhaal de oorspronkelijke poging zonder connection sharing. Controleer nieuwe login, juiste gebruiker en sudo. Een oude verbonden sessie is onvoldoende. Noteer oorzaak en correctie en ga zo nodig terug naar de serverconfiguratie.