Verbinding maken met uw server via SSH: Windows, macOS en Linux

Een net bestelde server komt zonder beeldscherm en zonder toetsenbord. De enige weg naar binnen loopt via SSH, het Secure Shell-protocol. Dit artikel begeleidt de eerste verbinding vanaf drie besturingssystemen, legt de vraag naar de vingerafdruk uit (die vrijwel elke beginner blind wegklikt) en laat zien hoe u bestanden overzet. Aan het slot volgt het deel dat de meeste handleidingen overslaan: wat u doet als het niet lukt, en waaraan u ziet dat het echt gelukt is.

Alle informatie is gecontroleerd op Debian 13, Debian 12, Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. Waar de vier van elkaar verschillen, staat dat er uitdrukkelijk bij. De commando's op de server draaien als root. Op uw eigen computer werkt u daarentegen met een gewoon gebruikersaccount, en daarom staat daar voor elk commando dat het systeem wijzigt een sudo.

Wat u nodig hebt voor de eerste verbinding

Drie gegevens volstaan: het IP-adres van de server, de gebruikersnaam en het wachtwoord of de private sleutel. Bij KernelHost vindt u het IP-adres en de inloggegevens na de uitrol in het klantenpaneel. De standaardgebruiker is bij een net geïnstalleerde KVM-rootserver of dedicated server vrijwel altijd root.

Als vierde gegeven komt de poort erbij. Standaard is dat 22. Alleen wanneer u die zelf hebt gewijzigd of het image hem heeft verlegd, hebt u een ander nummer nodig. Onthoud nu alvast een valkuil die u later tijd bespaart: ssh schrijft de poort klein (-p), scp schrijft hem groot (-P).

In de voorbeelden staat overal 203.0.113.10. Dat adres is officieel gereserveerd voor documentatie en bestaat niet. Vervang het door het IP-adres van uw server.

De eerste verbinding onder Linux en macOS

Beide systemen leveren de OpenSSH-client mee. Onder macOS opent u Terminal (in de map Hulpprogramma's), onder Linux een willekeurig terminalvenster. Het commando is op beide identiek:

ssh root@203.0.113.10

Draait SSH op een andere poort:

ssh -p 2222 root@203.0.113.10

Kent uw systeem geen ssh, wat bij zeer uitgeklede container- of minimale installaties voorkomt, dan controleert en installeert u het zo:

ssh -V
sudo apt update
apt-cache policy openssh-client
sudo apt install -y openssh-client

De volgorde is bewust zo gekozen. ssh -V is het controlecommando en geen bewijs van succes: antwoordt de shell met bash: ssh: command not found, dan ontbreekt het pakket openssh-client en installeert u dat alsnog met sudo apt install -y openssh-client. sudo apt update hoort vóór apt-cache policy openssh-client, omdat dat commando zonder ingelezen pakketlijsten leeg blijft of alleen Installed: (none) meldt. En de sudo is geen opsmuk: zonder beheerdersrechten breekt apt af met Could not open lock file /var/lib/apt/lists/lock.

ssh -V schrijft de versie naar de foutuitvoer, niet naar de standaarduitvoer. Dat is geen fout, maar van oudsher zo. Onder Debian 13 ziet u OpenSSH_10.0p2, onder Debian 12 OpenSSH_9.2p1, onder Ubuntu 24.04 OpenSSH_9.6p1 en onder Ubuntu 22.04 OpenSSH_8.9p1. Die nummers zijn later van belang, omdat het gedrag van scp precies tussen deze versies is veranderd.

De vingerafdruk, en waarom u die niet moet wegklikken

Bij de allereerste verbindingspoging vraagt SSH:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Wat hier gebeurt: elke SSH-server maakt bij zijn installatie een eigen sleutelpaar aan, de zogeheten hostkey. De vingerafdruk is een korte controlesom van het openbare deel. Uw client kent deze server nog niet en kan daarom niet garanderen dat aan de andere kant werkelijk uw server zit en niet iemand die zich ertussen heeft geschoven.

Typt u yes, dan wordt de vingerafdruk opgeslagen in ~/.ssh/known_hosts. Vanaf dat moment controleert uw client bij elke volgende verbinding stilzwijgend of de server dezelfde sleutel toont. Die ene vraag is dus het moment waarop het hele vertrouwensmodel wordt opgebouwd. Daarna vraagt niemand nog iets.

Echt controleren kunt u de vingerafdruk alleen via een tweede, onafhankelijke weg. Bij een KVM-server ligt de console in het klantenpaneel voor de hand: daar logt u lokaal in, volledig zonder netwerk, en laat u de vingerafdruk tonen.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

De uitvoer ziet er zo uit:

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Komt het deel achter SHA256: overeen met wat uw client toont, dan is alles in orde. Wilt u het formaat zonder risico uitproberen, maak dan lokaal een wegwerpsleutel aan:

ssh-keygen -t ed25519 -f /tmp/demo -N "" -C demo
ssh-keygen -lf /tmp/demo.pub

Twee opmerkingen uit de praktijk. Ten eerste: een server heeft meestal meerdere hostkeys (ED25519, ECDSA, RSA). Getoond wordt doorgaans de ED25519-sleutel, omdat moderne clients daar de voorkeur aan geven. Vergelijkt u per ongeluk met ssh_host_rsa_key.pub, dan komt er niets overeen, terwijl alles correct is. Ten tweede: StrictHostKeyChecking=no schakelt de controle volledig uit en is geen oplossing, maar het uitzetten van de beveiligingsfunctie. Hebt u automatisering nodig, dan is -o StrictHostKeyChecking=accept-new de juiste keuze: die accepteert onbekende servers automatisch, maar waarschuwt nog steeds bij wijzigingen.

Windows: de ingebouwde OpenSSH-client

Sinds Windows 10 versie 1809 levert Microsoft dezelfde OpenSSH-client mee die ook Linux en macOS gebruiken. U hebt dus geen extra programma meer nodig. Open PowerShell, de opdrachtprompt of Windows Terminal en typ hetzelfde commando als hierboven:

ssh root@203.0.113.10

Op Windows 10 en Windows 11 is de client een optioneel onderdeel dat bij de meeste installaties al actief is. Zo niet, dan controleert en installeert u het in een PowerShell met beheerdersrechten:

Get-WindowsCapability -Online -Name OpenSSH.Client*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Als alternatief via Instellingen, Systeem, Optionele onderdelen. De programma's staan daarna onder C:\Windows\System32\OpenSSH\, uw configuratie en de bekende hostkeys onder %USERPROFILE%\.ssh\, dus meestal C:\Users\Name\.ssh\known_hosts.

De Windows-versie loopt achter op de Linux-versie. Op actuele Windows 11-installaties meldt ssh -V meestal OpenSSH_for_Windows_9.5p2. Voor dagelijks gebruik is dat ruim voldoende.

Eén eigenaardigheid is er toch: de Windows-bestandsrechten. Legt u een private sleutel neer die ook andere accounts mogen lezen, dan weigert SSH dienst met Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Dat repareert u zo:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows: PuTTY

PuTTY was jarenlang de standaardweg onder Windows en is dat voor velen gebleven. Actueel is versie 0.84 van mei 2026. Download die uitsluitend van de site van de auteur (chiark.greenend.org.uk) en niet van downloadportalen, want vervalste PuTTY-versies met ingebouwde wachtwoorddiefstal zijn in het verleden meermaals opgedoken.

Het verloop: bij Host Name (or IP address) vult u het IP-adres in, bij Port 22, verbindingstype SSH, dan Open. Wilt u de verbinding bewaren, schrijf dan vooraf een naam in Saved Sessions en klik op Save. De gebruikersnaam vraagt PuTTY pas in het venster, of u legt hem vast onder Connection, Data, Auto-login username.

Bij de eerste verbindingsopbouw verschijnt het venster PuTTY Security Alert met de melding dat de hostkey niet in de cache staat. Het toont dezelfde SHA256-vingerafdruk die ook OpenSSH laat zien, dus u kunt de twee één op één vergelijken. Accept slaat de sleutel blijvend op, Connect Once verbindt alleen deze ene keer zonder op te slaan, Cancel breekt af.

Belangrijk verschil met OpenSSH: PuTTY heeft geen known_hosts-bestand. De sleutels belanden in het register onder HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Wie daar na een herinstallatie van zijn server wil opruimen, opent regedit en verwijdert het bijbehorende item. En nog een valkuil: PuTTY gebruikt een eigen sleutelformaat (.ppk). Een OpenSSH-sleutel moet u met PuTTYgen via Conversions, Import key omzetten voordat PuTTY hem kan gebruiken.

Bestanden overzetten met scp en sftp

scp kopieert bestanden zoals cp, alleen dan over het netwerk. Een bestand uploaden:

scp backup.tar.gz root@203.0.113.10:/root/

Een bestand downloaden (de punt aan het eind betekent: naar de huidige map):

scp root@203.0.113.10:/var/log/syslog .

Een hele map, en met een afwijkende poort:

scp -r website root@203.0.113.10:/var/www/
scp -P 2222 backup.tar.gz root@203.0.113.10:/root/

sftp is de interactieve variant en handig wanneer u eerst wilt kijken wat waar staat:

sftp root@203.0.113.10

Daarna werkt u met ls, cd, get bestand, put bestand aan de andere kant en met lls, lcd op uw eigen computer. bye beëindigt de sessie. Beide programma's bestaan ook onder Windows, ze horen bij dezelfde installatie. PuTTY levert met pscp en psftp eigen tegenhangers mee, en wie liever een grafische interface heeft, neemt WinSCP.

En hier het verschil waar velen over struikelen: sinds OpenSSH 9.0 draagt scp intern niet meer over via het oude SCP-protocol, maar via SFTP. Dat geldt voor Debian 13, Debian 12 en Ubuntu 24.04. Ubuntu 22.04 met OpenSSH 8.9 gebruikt nog de oude methode. In de praktijk merkt u dat op twee plekken. Jokertekens zoals *.log in een pad op het andere systeem worden anders geïnterpreteerd, en biedt dat systeem geen SFTP aan (bijvoorbeeld netwerkapparatuur of een beperkte chroot), dan breekt de overdracht af met:

subsystem request failed on channel 0
scp: Connection closed

De noodoplossing daarvoor is scp -O, dat dwingt het oude protocol af. De nette oplossing is om op de server de regel Subsystem sftp /usr/lib/openssh/sftp-server in /etc/ssh/sshd_config te activeren. Bij Debian en Ubuntu wordt het benodigde pakket openssh-sftp-server als afhankelijkheid van openssh-server meegeïnstalleerd, het ontbreekt dus alleen in zeer eigenzinnig samengestelde installaties.

De known_hosts-waarschuwing na een herinstallatie

U installeert uw server opnieuw, maakt verbinding, en in plaats van de prompt verschijnt een muur van uitroeptekens:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Offending ED25519 key in /home/tom/.ssh/known_hosts:7
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

Dat is geen fout, maar precies de functie waarvoor u de eerste keer yes hebt getypt. Bij een herinstallatie maakt de server nieuwe hostkeys aan, waardoor het oude item niet meer klopt. Dezelfde melding verschijnt overigens ook wanneer hetzelfde IP-adres aan een andere klant is doorgegeven of wanneer u een kopie van de server hebt gestart.

Denk voordat u het item verwijdert nog even na: hebt u zojuist werkelijk opnieuw geïnstalleerd? Zo ja, haal dan de oude regel weg:

ssh-keygen -R 203.0.113.10

Bij een afwijkende poort hoort het item tussen vierkante haken, anders vindt het commando niets:

ssh-keygen -R "[203.0.113.10]:2222"

Of er wel een item bestaat, laat ssh-keygen -F 203.0.113.10 zien. Nakijken met een teksteditor levert meestal weinig op, omdat Debian en Ubuntu de hostnamen in known_hosts standaard als hash opslaan. Zoeken kunt u daar dus niet, vandaar de twee commando's hierboven.

Bij de volgende verbindingspoging vraagt SSH weer om de vingerafdruk. Dat is het moment waarop u die opnieuw via de console in het klantenpaneel controleert, in plaats van reflexmatig yes te typen. Precies die tweede kans is de zin van de hele waarschuwing.

Onder Windows werkt ssh-keygen -R in PowerShell precies zo. Gebruikt u PuTTY, dan verwijdert u in plaats daarvan het registeritem, of bevestigt u in het venster WARNING - POTENTIAL SECURITY BREACH! met Accept dat de nieuwe sleutel opgeslagen moet worden.

Foutmeldingen letterlijk, en wat erachter zit

De volgende meldingen dekken in de praktijk de grote meerderheid van alle gevallen af.

• Connection refused: de verbinding bereikte de server wel, maar op de poort luistert niemand. Ofwel draait de SSH-service niet, ofwel luistert hij op een andere poort. Via de console controleert u met systemctl status ssh en ss -tlnp of poort 22 bezet is.
• Connection timed out: er kwam helemaal geen antwoord. Typisch voor een verkeerd IP-adres, een uitgeschakelde server of een firewall die pakketten weggooit in plaats van ze te weigeren. Controleer het IP-adres teken voor teken en de firewallregels.
• Permission denied, please try again.: gebruikersnaam of wachtwoord klopt niet. De meest voorkomende oorzaak is een verkeerde gebruiker, bijvoorbeeld root in plaats van ubuntu of andersom.
• Permission denied (publickey).: de server accepteert helemaal geen wachtwoorden, alleen sleutels. Bij veel cloud-images is dat de standaardinstelling. Ofwel legt u uw openbare sleutel vast, ofwel staat u via de console tijdelijk PasswordAuthentication yes toe.
• Too many authentication failures: uw agent biedt te veel sleutels achter elkaar aan en de server breekt eerder af. Oplossing: ssh -o IdentitiesOnly=yes -i ~/.ssh/mijn_sleutel root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! samen met Permissions 0644 for ... are too open: de private sleutel is voor anderen leesbaar en wordt daarom genegeerd. Onder Linux en macOS helpt chmod 600 op het sleutelbestand, onder Windows het commando icacls van hierboven.
• Bad owner or permissions on ~/.ssh/config: dezelfde oorzaak, alleen dan voor het configuratiebestand. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer: de verbinding is midden in de handshake afgebroken. In de praktijk vrijwel altijd een automatische blokkade na meerdere mislukte pogingen, bijvoorbeeld door fail2ban. Wacht de blokkadetijd af of hef hem via de console op met fail2ban-client unban IP-ADRES.
• no matching host key type found. Their offer: ssh-rsa: de server biedt alleen met SHA-1 ondertekende RSA-sleutels aan. Sinds OpenSSH 8.8 worden die geweigerd, en dat geldt als client voor alle vier de hier behandelde systemen. Het juiste antwoord is de oude server bijwerken, niet de client afzwakken.
• client_loop: send disconnect: Broken pipe: de sessie is in slaap gevallen en door een firewall of een router opgeruimd. Zet ServerAliveInterval 60 in ~/.ssh/config, dan blijft de lijn warm.

Basisregel voor al het werk aan de SSH-configuratie: laat een werkende sessie openstaan terwijl u test. Een herstart van de SSH-service gooit bestaande verbindingen er niet uit. Sluit u zichzelf met een foutieve configuratie buiten, dan komt u via die tweede sessie of via de console in het klantenpaneel weer binnen.

Verschillen tussen Debian 13, Debian 12, Ubuntu 24.04 en 22.04

Voor het opbouwen van de verbinding gedragen alle vier zich hetzelfde. Zodra u op de server iets wijzigt, lopen ze uiteen.

Socket-activering in plaats van een permanente service

Ubuntu start de SSH-service sinds 22.10 niet meer permanent, maar pas bij de eerste inkomende verbinding. Verantwoordelijk daarvoor is ssh.socket, niet ssh.service. Dat geldt voor Ubuntu 24.04 en, bij vers geïnstalleerde systemen, ook voor Debian 13. Debian 12 gebruikt nog de klassieke permanente service.

Twee gevolgen. Ten eerste verandert een Port 2222 in /etc/ssh/sshd_config daar helemaal niets, omdat niet langer sshd op de poort luistert, maar systemd. De poort hoort dan in een aanvullend bestand dat u met systemctl edit ssh.socket aanmaakt, met ListenStream= om de standaardwaarde terug te zetten en een tweede regel ListenStream=2222. Ten tweede kan systemctl reload ssh op vers geïnstalleerde Debian 13-systemen afbreken met fatal: Cannot bind any address. Neem in dat geval systemctl restart ssh.service of schakel de socket-activering met systemctl disable --now ssh.socket helemaal uit.

Algoritmen en oude ballast

Debian 13 levert OpenSSH 10.0 mee en kent DSA-sleutels helemaal niet meer, ook niet via een compatibiliteitsschakelaar. Wie nog een stokoude sleutel in gebruik heeft, maakt vooraf een nieuwe aan. Zeer recente clients (macOS 26.3 en nieuwer met OpenSSH 10.1 of hoger) tonen bovendien een melding wanneer de server geen kwantumveilige sleuteluitwisseling aanbiedt:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Dat is een waarschuwing, geen fout: de verbinding komt toch tot stand. Ze verdwijnt zodra de server nieuw genoeg is. Debian 12 en Ubuntu 24.04 voldoen aan de eis, Ubuntu 22.04 met OpenSSH 8.9 in de standaardconfiguratie niet.

Een woord over oudere versies

Debian 10 wordt sinds juni 2024 niet meer ondersteund, Ubuntu 20.04 sinds mei 2025. Beide krijgen geen beveiligingsupdates voor OpenSSH meer. Een server die via SSH vanaf internet bereikbaar is, hoort daar niet meer op te draaien.

Minder typen met ~/.ssh/config

Zodra u meer dan één server beheert, loont het configuratiebestand de moeite. Maak het aan en zet de rechten goed, anders weigert SSH het:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Een item daarin ziet er zo uit:

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

Daarna volstaat ssh web1, en ook scp bestand web1:/root/ werkt daarmee. Hetzelfde bestand begrijpt de Windows-client, daar staat het onder %USERPROFILE%\.ssh\config.

Of uw blok werkelijk aanslaat, hoeft u niet te raden. ssh -G toont de uiteindelijke configuratie zonder een verbinding op te bouwen:

ssh -G localhost

Vervang localhost door uw korte naam, en in de regels hostname, user en port ziet u zwart op wit wat SSH zo meteen gaat gebruiken. Een typefout in de Host-naam valt op die manier binnen twee seconden op, in plaats van na twintig minuten zoeken.

Waaraan u ziet dat het echt gelukt is

Een prompt die verschijnt, is nog geen bewijs. Met meerdere vensters open heeft menigeen al eens op de verkeerde server een rm afgevuurd. Vier korte commando's scheppen duidelijkheid:

hostname
id
cat /etc/os-release
uptime

hostname moet de naam van uw server tonen, niet die van uw laptop. id toont uid=0(root) wanneer u als root werkt. cat /etc/os-release noemt de distributie en de versie, dus bijvoorbeeld Debian GNU/Linux 13 (trixie) of Ubuntu 24.04.3 LTS. En uptime past bij de looptijd van een server, niet bij die van een werkplekcomputer die elke avond wordt uitgezet.

De snelste test of u werkelijk via SSH werkt en niet in een lokale terminal zit:

echo $SSH_CONNECTION

Komt er een regel met vier waarden terug (uw IP-adres, uw bronpoort, het server-IP, de doelpoort), dan bent u ingelogd. Blijft die leeg, dan typt u op dat moment op uw eigen computer. De sessie beëindigt u met exit of met de toetsencombinatie Ctrl en D.

Hoe het verdergaat

De volgende zinvolle stap is de overstap van wachtwoorden naar sleutels. Een SSH-sleutel valt niet te raden, en daarna kunt u het inloggen met een wachtwoord helemaal uitschakelen, waardoor het grootste deel van de geautomatiseerde aanvalspogingen in het niets loopt. Hoe dat gaat, staat in SSH-sleutelauthenticatie instellen. Daarna volgen de firewall en de automatische blokkade, beschreven in Server beveiligen na de installatie.

Voor de start geldt: bent u eenmaal binnen, hebt u de vingerafdruk gecontroleerd en weet u hoe u zichzelf na een herinstallatie weer binnenkrijgt, dan zit het moeilijkste deel erop. Al het overige gebeurt in een venster dat u nu kunt openen.