Per SSH auf den Server verbinden: Windows, macOS und Linux

Ein frisch bestellter Server kommt ohne Bildschirm und ohne Tastatur. Der einzige Weg hinein führt über SSH, das Secure Shell Protokoll. Dieser Artikel begleitet die erste Verbindung von drei Betriebssystemen aus, erklärt die Rückfrage nach dem Fingerabdruck (die fast alle Einsteiger blind wegklicken) und zeigt, wie du Dateien überträgst. Am Ende steht der Teil, den die meisten Anleitungen auslassen: was du tust, wenn es nicht klappt, und woran du erkennst, dass es wirklich geklappt hat.

Alle Angaben sind auf Debian 13, Debian 12, Ubuntu 24.04 LTS und Ubuntu 22.04 LTS geprüft. Wo sich die vier unterscheiden, steht es ausdrücklich dabei. Die Befehle auf dem Server laufen als root. Auf deinem eigenen Rechner arbeitest du dagegen mit einem normalen Benutzerkonto, deshalb steht dort vor jedem systemverändernden Befehl ein sudo.

Was du vor der ersten Verbindung brauchst

Drei Angaben reichen: die IP-Adresse des Servers, den Benutzernamen und das Passwort oder den privaten Schlüssel. Bei KernelHost findest du IP und Zugangsdaten nach der Bereitstellung im Kundenbereich. Standardbenutzer ist bei einem frisch installierten KVM-Rootserver oder Dedicated Server in aller Regel root.

Als vierte Angabe kommt der Port dazu. Standard ist 22. Nur wenn du ihn selbst geändert hast oder das Image ihn verlegt hat, brauchst du eine abweichende Zahl. Merke dir schon jetzt eine Falle, die später Zeit spart: ssh schreibt den Port klein (-p), scp schreibt ihn groß (-P).

In den Beispielen steht durchgehend 203.0.113.10. Diese Adresse ist offiziell für Dokumentation reserviert und existiert nicht. Ersetze sie durch die IP deines Servers.

Die erste Verbindung unter Linux und macOS

Beide Systeme bringen den OpenSSH-Client mit. Unter macOS öffnest du Terminal (im Ordner Dienstprogramme), unter Linux ein beliebiges Terminalfenster. Der Befehl ist auf beiden identisch:

ssh root@203.0.113.10

Läuft SSH auf einem anderen Port:

ssh -p 2222 root@203.0.113.10

Falls dein System kein ssh kennt, was bei sehr schlanken Container- oder Minimalinstallationen vorkommt, prüfst und installierst du so:

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

Die Reihenfolge ist mit Absicht so gewählt. ssh -V ist der Prüfbefehl und kein Erfolgsnachweis: Antwortet die Shell mit bash: ssh: command not found, fehlt das Paket openssh-client, und du installierst es mit sudo apt install -y openssh-client nach. sudo apt update gehört vor apt-cache policy openssh-client, weil dieser Befehl ohne eingelesene Paketlisten leer bleibt oder nur Installed: (none) meldet. Und das sudo ist kein Zierrat: Ohne Administratorrechte bricht apt mit Could not open lock file /var/lib/apt/lists/lock ab.

ssh -V gibt die Version auf die Fehlerausgabe aus, nicht auf die Standardausgabe. Das ist kein Fehler, sondern seit jeher so. Unter Debian 13 siehst du OpenSSH_10.0p2, unter Debian 12 OpenSSH_9.2p1, unter Ubuntu 24.04 OpenSSH_9.6p1 und unter Ubuntu 22.04 OpenSSH_8.9p1. Diese Zahlen sind später wichtig, weil sich das Verhalten von scp genau zwischen diesen Versionen geändert hat.

Der Fingerabdruck, und warum du ihn nicht wegklicken solltest

Beim allerersten Verbindungsversuch fragt 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])?

Was hier passiert: Jeder SSH-Server erzeugt bei seiner Installation ein eigenes Schlüsselpaar, den sogenannten Hostkey. Der Fingerabdruck ist eine kurze Prüfsumme des öffentlichen Teils. Dein Client kennt diesen Server noch nicht und kann deshalb nicht garantieren, dass am anderen Ende wirklich dein Server sitzt und nicht jemand, der sich dazwischengeschaltet hat.

Tippst du yes, wird der Fingerabdruck in ~/.ssh/known_hosts gespeichert. Ab dann prüft dein Client bei jeder weiteren Verbindung stillschweigend, ob der Server denselben Schlüssel vorzeigt. Diese eine Frage ist also der Moment, in dem das ganze Vertrauensmodell aufgebaut wird. Danach fragt niemand mehr.

Richtig prüfen kannst du ihn nur über einen zweiten, unabhängigen Weg. Bei einem KVM-Server bietet sich die Konsole im Kundenbereich an: Dort meldest du dich lokal an, ganz ohne Netzwerk, und lässt dir den Fingerabdruck ausgeben.

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

Die Ausgabe sieht so aus:

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Stimmt der Teil hinter SHA256: mit dem überein, was dein Client zeigt, ist alles in Ordnung. Wenn du das Format gefahrlos ausprobieren möchtest, erzeuge dir lokal einen Wegwerfschlüssel:

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

Zwei Anmerkungen aus der Praxis. Erstens: Ein Server hat meist mehrere Hostkeys (ED25519, ECDSA, RSA). Angezeigt wird üblicherweise der ED25519-Schlüssel, weil moderne Clients ihn bevorzugen. Vergleichst du versehentlich mit ssh_host_rsa_key.pub, passt nichts zusammen, obwohl alles korrekt ist. Zweitens: StrictHostKeyChecking=no schaltet die Prüfung komplett ab und ist keine Lösung, sondern das Abschalten der Sicherheitsfunktion. Wenn du Automatisierung brauchst, ist -o StrictHostKeyChecking=accept-new die richtige Wahl: Sie akzeptiert unbekannte Server automatisch, warnt aber weiterhin bei Änderungen.

Windows: der eingebaute OpenSSH-Client

Seit Windows 10 Version 1809 liefert Microsoft denselben OpenSSH-Client mit, den auch Linux und macOS verwenden. Du brauchst also kein Zusatzprogramm mehr. Öffne PowerShell, die Eingabeaufforderung oder Windows Terminal und tippe denselben Befehl wie oben:

ssh root@203.0.113.10

Auf Windows 10 und Windows 11 ist der Client eine optionale Komponente, die bei den meisten Installationen bereits aktiv ist. Wenn nicht, prüfst und installierst du sie in einer PowerShell mit Administratorrechten:

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

Alternativ über Einstellungen, System, Optionale Features. Die Programme liegen anschließend unter C:\Windows\System32\OpenSSH\, deine Konfiguration und die bekannten Hostkeys unter %USERPROFILE%\.ssh\, also typischerweise C:\Users\Name\.ssh\known_hosts.

Die Windows-Version hinkt der Linux-Version hinterher. Auf aktuellen Windows-11-Installationen meldet ssh -V meist OpenSSH_for_Windows_9.5p2. Für den Alltag reicht das vollkommen.

Eine Eigenheit gibt es doch: Windows-Dateirechte. Legst du einen privaten Schlüssel ab, den auch andere Konten lesen dürfen, verweigert SSH den Dienst mit Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Das reparierst du so:

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

Windows: PuTTY

PuTTY war jahrelang der Standardweg unter Windows und ist es für viele geblieben. Aktuell ist Version 0.84 vom Mai 2026. Lade sie ausschließlich von der Seite des Autors (chiark.greenend.org.uk) und nicht von Downloadportalen, denn gefälschte PuTTY-Versionen mit eingebautem Passwortdiebstahl gab es in der Vergangenheit mehrfach.

Der Ablauf: In Host Name (or IP address) trägst du die IP ein, bei Port 22, Verbindungstyp SSH, dann Open. Willst du die Verbindung behalten, schreibst du vorher einen Namen in Saved Sessions und klickst Save. Den Benutzernamen fragt PuTTY erst im Fenster ab, oder du hinterlegst ihn unter Connection, Data, Auto-login username.

Beim ersten Verbindungsaufbau erscheint das Fenster PuTTY Security Alert mit dem Hinweis, dass der Hostkey nicht zwischengespeichert ist. Es zeigt denselben SHA256-Fingerabdruck, den auch OpenSSH anzeigt, du kannst die beiden also eins zu eins vergleichen. Accept speichert den Schlüssel dauerhaft, Connect Once verbindet nur dieses eine Mal ohne zu speichern, Cancel bricht ab.

Wichtiger Unterschied zu OpenSSH: PuTTY hat keine known_hosts-Datei. Die Schlüssel landen in der Registry unter HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Wer nach einer Neuinstallation seines Servers dort aufräumen will, öffnet regedit und löscht den passenden Eintrag. Und noch eine Stolperfalle: PuTTY nutzt ein eigenes Schlüsselformat (.ppk). Einen OpenSSH-Schlüssel musst du mit PuTTYgen über Conversions, Import key umwandeln, bevor PuTTY ihn verwenden kann.

Dateien übertragen mit scp und sftp

scp kopiert Dateien wie cp, nur über das Netz. Eine Datei hinaufladen:

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

Eine Datei herunterladen (der Punkt am Ende bedeutet: in das aktuelle Verzeichnis):

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

Ein ganzes Verzeichnis, und mit abweichendem Port:

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

sftp ist die interaktive Variante und praktisch, wenn du erst schauen willst, was wo liegt:

sftp root@203.0.113.10

Danach arbeitest du mit ls, cd, get datei, put datei auf der Gegenseite und mit lls, lcd auf deinem eigenen Rechner. bye beendet die Sitzung. Beide Programme gibt es auch unter Windows, sie sind Teil derselben Installation. PuTTY bringt mit pscp und psftp eigene Gegenstücke mit, wer eine Oberfläche möchte, nimmt WinSCP.

Und hier der Unterschied, über den viele stolpern: Seit OpenSSH 9.0 überträgt scp intern nicht mehr über das alte SCP-Protokoll, sondern über SFTP. Das betrifft Debian 13, Debian 12 und Ubuntu 24.04. Ubuntu 22.04 mit OpenSSH 8.9 nutzt noch das alte Verfahren. Praktisch merkst du das an zwei Stellen. Platzhalter wie *.log in einem entfernten Pfad werden anders ausgewertet, und wenn die Gegenstelle kein SFTP anbietet (etwa Netzwerkgeräte oder ein eingeschränktes chroot), bricht die Übertragung ab mit:

subsystem request failed on channel 0
scp: Connection closed

Die Notlösung dafür ist scp -O, das erzwingt das alte Protokoll. Die saubere Lösung ist, auf dem Server die Zeile Subsystem sftp /usr/lib/openssh/sftp-server in /etc/ssh/sshd_config zu aktivieren. Bei Debian und Ubuntu wird das nötige Paket openssh-sftp-server als Abhängigkeit von openssh-server mitinstalliert, es fehlt also nur in sehr eigenwillig zusammengebauten Installationen.

Die known_hosts-Warnung nach einer Neuinstallation

Du installierst deinen Server neu, verbindest dich, und statt der Eingabeaufforderung erscheint eine Wand aus Ausrufezeichen:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.

Das ist kein Fehler, sondern genau die Funktion, für die du beim ersten Mal yes getippt hast. Bei einer Neuinstallation erzeugt der Server neue Hostkeys, der alte Eintrag passt nicht mehr. Dieselbe Meldung erscheint übrigens auch, wenn dieselbe IP-Adresse an einen anderen Kunden weitergegeben wurde oder wenn du eine Kopie des Servers gestartet hast.

Bevor du den Eintrag löschst, überlege kurz: Hast du gerade wirklich neu installiert? Wenn ja, entferne die alte Zeile:

ssh-keygen -R 203.0.113.10

Bei abweichendem Port gehört der Eintrag in eckige Klammern, sonst findet der Befehl nichts:

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

Ob ein Eintrag überhaupt existiert, verrät ssh-keygen -F 203.0.113.10. Nachschauen mit einem Texteditor bringt meist wenig, weil Debian und Ubuntu die Hostnamen in known_hosts standardmäßig als Hash speichern. Suchen kannst du dort also nicht, deshalb die beiden Befehle oben.

Beim nächsten Verbindungsversuch fragt SSH wieder nach dem Fingerabdruck. Das ist der Moment, in dem du ihn erneut über die Konsole im Kundenbereich gegenprüfst, statt reflexhaft yes zu tippen. Genau diese zweite Chance ist der Sinn der ganzen Warnung.

Unter Windows funktioniert ssh-keygen -R in PowerShell genauso. Nutzt du PuTTY, löschst du stattdessen den Registry-Eintrag oder bestätigst im Fenster WARNING - POTENTIAL SECURITY BREACH! mit Accept, dass der neue Schlüssel gespeichert werden soll.

Fehlermeldungen im Wortlaut, und was dahintersteckt

Die folgenden Meldungen decken erfahrungsgemäß die große Mehrheit aller Fälle ab.

• Connection refused: Die Verbindung kam bis zum Server durch, aber auf dem Port hört niemand zu. Entweder läuft der SSH-Dienst nicht, oder er hört auf einem anderen Port. Über die Konsole prüfst du mit systemctl status ssh und ss -tlnp, ob Port 22 belegt ist.
• Connection timed out: Es kam gar keine Antwort. Typisch für eine falsche IP, einen ausgeschalteten Server oder eine Firewall, die Pakete verwirft statt sie abzulehnen. Prüfe die IP-Adresse Zeichen für Zeichen und die Firewallregeln.
• Permission denied, please try again.: Benutzername oder Passwort stimmen nicht. Häufigste Ursache ist ein falscher Benutzer, etwa root statt ubuntu oder umgekehrt.
• Permission denied (publickey).: Der Server akzeptiert überhaupt keine Passwörter, sondern nur Schlüssel. Bei vielen Cloud-Images ist das voreingestellt. Entweder hinterlegst du deinen öffentlichen Schlüssel, oder du erlaubst über die Konsole vorübergehend PasswordAuthentication yes.
• Too many authentication failures: Dein Agent bietet zu viele Schlüssel nacheinander an, der Server bricht vorher ab. Abhilfe: ssh -o IdentitiesOnly=yes -i ~/.ssh/mein_schluessel root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! zusammen mit Permissions 0644 for ... are too open: Der private Schlüssel ist für andere lesbar und wird deshalb ignoriert. Unter Linux und macOS hilft chmod 600 auf die Schlüsseldatei, unter Windows der icacls-Befehl weiter oben.
• Bad owner or permissions on ~/.ssh/config: Dieselbe Ursache, nur für die Konfigurationsdatei. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer: Die Verbindung wurde mitten im Handschlag abgebrochen. In der Praxis fast immer eine automatische Sperre nach mehreren Fehlversuchen, etwa durch fail2ban. Warte die Sperrzeit ab oder hebe sie über die Konsole mit fail2ban-client unban IPADRESSE auf.
• no matching host key type found. Their offer: ssh-rsa: Der Server bietet nur SHA-1-signierte RSA-Schlüssel an. Seit OpenSSH 8.8 werden die abgelehnt, das betrifft alle vier hier behandelten Systeme als Client. Die richtige Antwort ist, den alten Server zu aktualisieren, nicht den Client aufzuweichen.
• client_loop: send disconnect: Broken pipe: Die Sitzung ist eingeschlafen und wurde von einer Firewall oder einem Router aufgeräumt. Trage in ~/.ssh/config ServerAliveInterval 60 ein, dann bleibt die Leitung warm.

Grundregel für alle Arbeiten an der SSH-Konfiguration: Lass eine funktionierende Sitzung offen, während du testest. Ein Neustart des SSH-Dienstes wirft bestehende Verbindungen nicht hinaus. Sperrst du dich mit einer fehlerhaften Konfiguration aus, kommst du über diese zweite Sitzung oder über die Konsole im Kundenbereich wieder herein.

Unterschiede zwischen Debian 13, Debian 12, Ubuntu 24.04 und 22.04

Für den reinen Verbindungsaufbau verhalten sich alle vier gleich. Sobald du auf dem Server etwas änderst, laufen sie auseinander.

Socket-Aktivierung statt Dauerdienst

Ubuntu startet den SSH-Dienst seit 22.10 nicht mehr dauerhaft, sondern erst bei der ersten eingehenden Verbindung. Zuständig ist dafür ssh.socket, nicht ssh.service. Das gilt für Ubuntu 24.04 und, bei frisch installierten Systemen, auch für Debian 13. Debian 12 nutzt noch den klassischen Dauerdienst.

Zwei Konsequenzen. Erstens ändert ein Port 2222 in /etc/ssh/sshd_config dort gar nichts, weil nicht mehr sshd auf dem Port lauscht, sondern systemd. Der Port gehört dann in eine Ergänzungsdatei, die du mit systemctl edit ssh.socket anlegst, mit ListenStream= zum Zurücksetzen der Vorgabe und einer zweiten Zeile ListenStream=2222. Zweitens kann systemctl reload ssh auf frisch installierten Debian-13-Systemen mit fatal: Cannot bind any address abbrechen. In dem Fall nimm systemctl restart ssh.service oder schalte die Socket-Aktivierung mit systemctl disable --now ssh.socket ganz ab.

Algorithmen und Altlasten

Debian 13 bringt OpenSSH 10.0 mit und kennt DSA-Schlüssel überhaupt nicht mehr, auch nicht über Kompatibilitätsschalter. Wer noch einen uralten Schlüssel im Einsatz hat, erzeugt vorher einen neuen. Sehr aktuelle Clients (macOS 26.3 und neuer mit OpenSSH 10.1 oder höher) zeigen außerdem einen Hinweis an, wenn der Server keinen quantensicheren Schlüsselaustausch anbietet:

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

Das ist eine Warnung, kein Fehler, die Verbindung kommt trotzdem zustande. Sie verschwindet, sobald der Server neu genug ist. Debian 12 und Ubuntu 24.04 erfüllen die Anforderung, Ubuntu 22.04 mit OpenSSH 8.9 in der Standardkonfiguration nicht.

Ein Wort zu älteren Versionen

Debian 10 ist seit Juni 2024 ohne Unterstützung, Ubuntu 20.04 seit Mai 2025. Beide bekommen keine Sicherheitsaktualisierungen für OpenSSH mehr. Ein Server, der über SSH aus dem Internet erreichbar ist, sollte dort nicht mehr stehen.

Weniger tippen mit ~/.ssh/config

Sobald du mehr als einen Server betreust, lohnt sich die Konfigurationsdatei. Lege sie an und setze die Rechte, sonst verweigert SSH sie:

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

Ein Eintrag darin sieht so aus:

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

Danach genügt ssh web1, und auch scp datei web1:/root/ funktioniert damit. Dieselbe Datei versteht der Windows-Client, sie liegt dort unter %USERPROFILE%\.ssh\config.

Ob dein Block tatsächlich greift, musst du nicht raten. ssh -G zeigt die endgültige Konfiguration an, ohne eine Verbindung aufzubauen:

ssh -G localhost

Ersetze localhost durch deinen Kurznamen, und du siehst in den Zeilen hostname, user und port schwarz auf weiß, was SSH gleich verwenden wird. Ein Tippfehler im Host-Namen fällt so in zwei Sekunden auf statt nach zwanzig Minuten Fehlersuche.

Woran du erkennst, dass es wirklich funktioniert hat

Eine Eingabeaufforderung, die erscheint, ist noch kein Beweis. Bei mehreren offenen Fenstern hat schon mancher auf dem falschen Server ein rm abgesetzt. Vier kurze Befehle schaffen Klarheit:

hostname
id
cat /etc/os-release
uptime

hostname muss den Namen deines Servers zeigen, nicht den deines Notebooks. id zeigt uid=0(root), wenn du als root arbeitest. cat /etc/os-release nennt Distribution und Version, also etwa Debian GNU/Linux 13 (trixie) oder Ubuntu 24.04.3 LTS. Und uptime passt zur Laufzeit eines Servers, nicht zu der eines Arbeitsplatzrechners, der jeden Abend heruntergefahren wird.

Der schnellste Test, ob du wirklich über SSH und nicht in einem lokalen Terminal sitzt:

echo $SSH_CONNECTION

Kommt eine Zeile mit vier Werten (deine IP, dein Quellport, die Server-IP, der Zielport), bist du eingeloggt. Bleibt sie leer, tippst du gerade auf deinem eigenen Rechner. Beendet wird die Sitzung mit exit oder der Tastenkombination Strg und D.

Wie es weitergeht

Der nächste sinnvolle Schritt ist der Umstieg von Passwörtern auf Schlüssel. Ein SSH-Schlüssel lässt sich nicht erraten, und anschließend kannst du die Passwortanmeldung ganz abschalten, was den größten Teil der automatisierten Angriffsversuche ins Leere laufen lässt. Wie das geht, steht in SSH-Key-Authentifizierung einrichten. Danach folgen Firewall und Sperrautomatik, beschrieben in Server absichern nach der Installation.

Für den Anfang gilt: Wenn du einmal drin bist, den Fingerabdruck geprüft hast und weißt, wie du dich nach einer Neuinstallation wieder hereinbringst, ist der schwierigste Teil geschafft. Alles Weitere passiert in einem Fenster, das du jetzt öffnen kannst.