Version vom 14. April 2026, 14:28 Uhr

SSH-Verbindungsaufbau

SSH baut eine Verbindung in drei Phasen auf:

Verschlüsselter Kanal wird aufgebaut
Nutzer wird authentifiziert
Eigentliche Sitzung beginnt

Hinweis: Dieses Wissen hilft dir, Fehlermeldungen zu verstehen – du brauchst es nicht, um SSH zu benutzen.

Die drei Phasen im Überblick

Phase 1 – Transport Layer & Key Exchange: Client und Server einigen sich auf einen gemeinsamen, geheimen Schlüssel – ohne ihn jemals direkt zu übertragen.
Phase 2 – User Authentication: Der Server prüft, ob der Client wirklich der ist, der er vorgibt zu sein.
Phase 3 – Session Phase: Die eigentliche Arbeit beginnt – Befehle, Dateiübertragungen, Tunnel usw.

Phase 1: Transport Layer & Key Exchange

Begrüßung (Hello)

Client schickt dem Server, welche Verfahren er unterstützt
Server wählt passende Verfahren aus
Server schickt seinen öffentlichen Host Key mit

Host-Key-Prüfung

Client empfängt den öffentlichen Host Key des Servers
SSH prüft: Ist das wirklich der richtige Server?
Prüfung erfolgt anhand ~/.ssh/known_hosts
Beim ersten Verbindungsaufbau: SSH zeigt den Fingerprint an und fragt nach Bestätigung
Nach Bestätigung: Public Key wird in known_hosts gespeichert
Bei weiteren Verbindungen: SSH vergleicht automatisch

Warnung: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Der Server präsentiert einen anderen Key als beim letzten Mal
Mögliche Ursachen: Angriff oder Server neu aufgesetzt
Im Zweifel beim Administrator nachfragen

Diffie-Hellman Key Exchange

Client und Server tauschen öffentliche Werte aus
Beide berechnen daraus unabhängig denselben Session Key
Der Session Key wird nie übertragen
Ein Lauscher kann den Key nicht ableiten

Ab jetzt alles verschlüsselt

Beide Seiten besitzen nun denselben Session Key
Ab jetzt ist die gesamte Kommunikation verschlüsselt

Phase 2: User Authentication

Server prüft: Wer will sich einloggen – und hat diese Person Berechtigung?
Sicherste Methode: Public-Key-Authentifizierung

Ablauf:

Client schickt seinen öffentlichen Schlüssel
Server prüft, ob dieser in ~/.ssh/authorized_keys steht
Server schickt eine Challenge
Client signiert sie mit seinem privaten Schlüssel
Server prüft die Signatur → Erfolg

Der private Schlüssel verlässt nie den eigenen Rechner
Sicherer als ein Passwort, weil die Signatur ohne privaten Schlüssel nicht reproduzierbar ist

Phase 3: Session Phase

Verbindung steht – die eigentliche Arbeit beginnt
SSH öffnet Channels für verschiedene Aufgaben:

Channel-Typ	Verwendung	Beispiel
`shell`	Interaktive Terminal-Sitzung	`ssh user@server`
`exec`	Einzelnen Befehl ausführen	`ssh user@server ls -la`
`subsystem sftp`	Dateiübertragung	`sftp user@server`
`direct-tcpip`	Port-Forwarding / Tunnel	`ssh -L 8080:localhost:80 user@server`

Alle Daten sind verschlüsselt und integritätsgeschützt

Häufige Fehlermeldungen

Host-Key-Warnung

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Ursache: Host Key hat sich geändert (z. B. nach Neuinstallation)
Lösung:

ssh-keygen -R server.example.com

Permission denied (publickey)

Permission denied (publickey).

Ursache: Public Key nicht in ~/.ssh/authorized_keys, oder Berechtigungen falsch
Lösung:

ssh-copy-id user@server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verwendete Algorithmen

Kategorie	Empfehlung	Zweck
Key Exchange	`curve25519-sha256`	Session Key ableiten
Host Key	`ssh-ed25519`	Server-Identität beweisen
Verschlüsselung	`aes256-gcm@openssh.com`	Datenverschlüsselung
Integrität	`hmac-sha2-256-etm`	Manipulation erkennen
Client-Schlüssel	`ed25519`	User Authentication

Siehe auch

SSH – Grundlagen und Einführung
OpenSSH – Die meistgenutzte SSH-Implementierung
SSH-Keygen – Schlüsselpaare generieren
SFTP – Sicherer Dateitransfer über SSH
SSH-Tunnel – Port-Forwarding und Tunneling

Weblinks

openssh.com – Offizielle OpenSSH-Website
RFC 4251 – SSH Protocol Architecture
RFC 4252 – SSH Authentication Protocol

@@ Zeile 1: / Zeile 1: @@
 = SSH-Verbindungsaufbau =
-SSH baut eine Verbindung in drei aufeinanderfolgenden Phasen auf. Dieser Artikel erklärt, was dabei Schritt für Schritt im Hintergrund passiert – verständlich auch ohne tiefes Vorwissen.
+SSH baut eine Verbindung in drei Phasen auf:
+* Verschlüsselter Kanal wird aufgebaut
+* Nutzer wird authentifiziert
+* Eigentliche Sitzung beginnt
-'''Hinweis für Einsteiger:''' Du musst den Verbindungsaufbau nicht auswendig kennen, um SSH zu benutzen. Dieses Wissen hilft dir aber, Fehlermeldungen zu verstehen und zu begreifen, warum SSH so sicher ist.
+'''Hinweis:''' Dieses Wissen hilft dir, Fehlermeldungen zu verstehen – du brauchst es nicht, um SSH zu benutzen.
 == Die drei Phasen im Überblick ==
@@ Zeile 12: / Zeile 15: @@
 == Phase 1: Transport Layer & Key Exchange ==
-In dieser Phase wird der verschlüsselte Kanal aufgebaut. Am Ende kennen beide Seiten einen gemeinsamen geheimen Schlüssel – ohne dass dieser jemals über das Netzwerk gesendet wurde.
 === Begrüßung (Hello) ===
-Der Client nimmt Kontakt auf und schickt ein '''ClientHello'''. Darin teilt er dem Server mit, welche kryptographischen Verfahren er unterstützt:
+* Client schickt dem Server, welche Verfahren er unterstützt
+* Server wählt passende Verfahren aus
+* Server schickt seinen öffentlichen Host Key mit
-* '''KEX-Algorithmen:''' Verfahren für den Schlüsselaustausch (z. B. <code>curve25519-sha256</code>)
+=== Host-Key-Prüfung ===
-* '''Host-Key-Algorithmen:''' Wie der Server sich ausweisen kann (z. B. <code>ssh-ed25519</code>)
-* '''Cipher-Algorithmen:''' Verschlüsselungsverfahren (z. B. <code>aes256-gcm</code>)
-* '''MAC-Algorithmen:''' Methoden zur Integritätsprüfung (z. B. <code>hmac-sha2-256</code>)
-Der Server antwortet mit einem '''ServerHello''': Er wählt aus der Liste die Algorithmen aus, die er ebenfalls unterstützt, und schickt außerdem seinen '''öffentlichen Host Key''' mit.
+* Client empfängt den öffentlichen Host Key des Servers
+* SSH prüft: ''Ist das wirklich der richtige Server?''
+* Prüfung erfolgt anhand <code>~/.ssh/known_hosts</code>
+* Beim ersten Verbindungsaufbau: SSH zeigt den Fingerprint an und fragt nach Bestätigung
+* Nach Bestätigung: Public Key wird in <code>known_hosts</code> gespeichert
+* Bei weiteren Verbindungen: SSH vergleicht automatisch
-=== Host-Key-Prüfung ===
+'''Warnung:''' <code>WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!</code>
-Der Client hat jetzt den öffentlichen Host Key des Servers. Jetzt stellt sich die Frage: ''Ist das wirklich der richtige Server – oder wurde die Verbindung abgefangen?''
+* Der Server präsentiert einen anderen Key als beim letzten Mal
-SSH überprüft das mithilfe der Datei <code>~/.ssh/known_hosts</code>. Dort werden beim ersten Verbindungsaufbau die öffentlichen Host Keys bekannter Server gespeichert. Beim allerersten Verbindungsaufbau zu einem neuen Server zeigt SSH einen Fingerprint des Host Keys an – eine kompakte Hash-Darstellung – und fragt, ob du dem Server vertraust. Erst nach deiner Bestätigung wird der vollständige Public Key in <code>known_hosts</code> gespeichert. Bei allen weiteren Verbindungen vergleicht SSH den gespeicherten Key automatisch mit dem vom Server.
+* Mögliche Ursachen: Angriff oder Server neu aufgesetzt
-'''Warnung:''' Wenn SSH die Meldung <code>WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!</code> anzeigt, präsentiert der Server einen anderen Key als beim letzten Mal. Das kann ein Hinweis auf einen Angriff sein – oder einfach darauf, dass der Server neu aufgesetzt wurde. Im Zweifel beim Administrator nachfragen, bevor du fortfährst.
+* Im Zweifel beim Administrator nachfragen
 === Diffie-Hellman Key Exchange ===
-Jetzt passiert etwas scheinbar Magisches: Client und Server einigen sich auf einen gemeinsamen geheimen Schlüssel – '''ohne ihn jemals zu übertragen'''.
+* Client und Server tauschen öffentliche Werte aus
+* Beide berechnen daraus unabhängig denselben Session Key
+* Der Session Key wird nie übertragen
+* Ein Lauscher kann den Key nicht ableiten
-Das Verfahren heißt '''Diffie-Hellman''' (oder in moderner Form ECDH). Die klassische Analogie ist das Farbmischen: Stell dir vor, beide Seiten haben eine gemeinsame Ausgangsfarbe (öffentlich bekannt). Jeder mischt seine eigene Geheimfarbe dazu – und tauscht das Ergebnis aus. Aus diesem Ergebnis kann jeder seine eigene Geheimfarbe wieder herausrechnen und erhält dadurch dieselbe Endfarbe. Ein Lauscher sieht nur die gemischten Farben, nie die Geheimfarben.
+=== Ab jetzt alles verschlüsselt ===
-Ablauf im Detail:
+* Beide Seiten besitzen nun denselben Session Key
+* Ab jetzt ist die gesamte Kommunikation verschlüsselt
-# Client erzeugt ein zufälliges privates Geheimnis und berechnet daraus einen '''Public Value'''
+== Phase 2: User Authentication ==
-# Server macht dasselbe und schickt seinen Public Value sowie eine '''Signatur''' (erstellt mit dem privaten Host Key)
-# Client prüft die Signatur mit dem öffentlichen Host Key des Servers → bestätigt die Serveridentität
-# Beide berechnen unabhängig voneinander denselben '''Session Key'''
-=== Session Key – ab jetzt alles verschlüsselt ===
+* Server prüft: ''Wer will sich einloggen – und hat diese Person Berechtigung?''
+* Sicherste Methode: '''Public-Key-Authentifizierung'''
-Aus den ausgetauschten Werten berechnen beide Seiten unabhängig voneinander denselben '''symmetrischen Session Key'''. Ab diesem Moment ist die gesamte Kommunikation verschlüsselt – auch die noch folgende Authentifizierung des Nutzers.
+Ablauf:
+# Client schickt seinen öffentlichen Schlüssel
+# Server prüft, ob dieser in <code>~/.ssh/authorized_keys</code> steht
+# Server schickt eine Challenge
+# Client signiert sie mit seinem privaten Schlüssel
+# Server prüft die Signatur → Erfolg
-== Phase 2: User Authentication (Public Key) ==
+* Der private Schlüssel verlässt nie den eigenen Rechner
+* Sicherer als ein Passwort, weil die Signatur ohne privaten Schlüssel nicht reproduzierbar ist
-Der Kanal ist jetzt verschlüsselt. Jetzt muss der Server wissen: ''Wer will sich hier einloggen – und hat diese Person die Berechtigung?''
+== Phase 3: Session Phase ==
-Die sicherste Methode ist die '''Public-Key-Authentifizierung'''. Dabei beweist der Client, dass er im Besitz eines privaten Schlüssels ist – ohne diesen jemals zu senden.
+* Verbindung steht – die eigentliche Arbeit beginnt
+* SSH öffnet Channels für verschiedene Aufgaben:
-Vorbedingung: Der öffentliche Schlüssel des Clients muss vorher auf dem Server hinterlegt werden:
- ssh-copy-id user@server
-Ablauf der Authentifizierung:
-# Client schickt einen '''Auth Request''' mit Benutzername, Methode „publickey" und dem verwendeten öffentlichen Schlüssel
-# Server prüft: Ist dieser Public Key in <code>~/.ssh/authorized_keys</code> eingetragen?
-# Wenn ja: Server schickt eine '''Challenge''' (verschlüsselte Zufallsdaten)
-# Client signiert die Challenge mit seinem '''privaten Schlüssel''' und sendet die Signatur zurück
-# Server prüft die Signatur mit dem öffentlichen Schlüssel → gültig → '''Auth SUCCESS'''
-'''Warum ist das sicherer als ein Passwort?''' Der private Schlüssel verlässt den eigenen Rechner nie. Selbst wenn ein Angreifer den gesamten Netzwerkverkehr aufzeichnet, kann er sich nicht einloggen – ohne den privaten Schlüssel ist die Signatur nicht reproduzierbar.
-== Phase 3: Session Phase (Channels) ==
-Die Authentifizierung ist erfolgreich. Jetzt öffnet SSH einen oder mehrere '''Channels''' – logische Kanäle innerhalb der verschlüsselten Verbindung.
 {| class="wikitable"
@@ Zeile 78: / Zeile 75: @@
 | <code>exec</code> || Einzelnen Befehl ausführen || <code>ssh user@server ls -la</code>
 |-
-| <code>subsystem sftp</code> || Dateiübertragung per SFTP || <code>sftp user@server</code>
+| <code>subsystem sftp</code> || Dateiübertragung || <code>sftp user@server</code>
 |-
 | <code>direct-tcpip</code> || Port-Forwarding / Tunnel || <code>ssh -L 8080:localhost:80 user@server</code>
 |}
-Alle Daten in diesen Channels sind symmetrisch verschlüsselt und integritätsgeschützt – niemand kann die Daten unbemerkt verändern.
+* Alle Daten sind verschlüsselt und integritätsgeschützt
 == Häufige Fehlermeldungen ==
@@ Zeile 91: / Zeile 88: @@
   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
-'''Ursache:''' Der Host Key des Servers hat sich geändert (z. B. nach Neuinstallation des Servers).
+* Ursache: Host Key hat sich geändert (z. B. nach Neuinstallation)
+* Lösung:
-'''Lösung:''' Den alten Eintrag aus <code>~/.ssh/known_hosts</code> entfernen:
   ssh-keygen -R server.example.com
@@ Zeile 100: / Zeile 96: @@
   Permission denied (publickey).
-'''Ursache:''' Der öffentliche Schlüssel ist nicht in <code>~/.ssh/authorized_keys</code> des Servers eingetragen, oder die Dateiberechtigungen stimmen nicht.
+* Ursache: Public Key nicht in <code>~/.ssh/authorized_keys</code>, oder Berechtigungen falsch
+* Lösung:
-'''Lösung:'''
   ssh-copy-id user@server
-Berechtigungen auf dem Server prüfen:
   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
@@ Zeile 112: / Zeile 105: @@
 {| class="wikitable"
-! Kategorie !! Moderne Empfehlung !! Zweck
+! Kategorie !! Empfehlung !! Zweck
 |-
-| Key Exchange (KEX) || <code>curve25519-sha256</code> || Gemeinsamen Session Key ableiten
+| Key Exchange || <code>curve25519-sha256</code> || Session Key ableiten
 |-
 | Host Key || <code>ssh-ed25519</code> || Server-Identität beweisen
 |-
-| Symmetrische Verschlüsselung || <code>aes256-gcm@openssh.com</code> || Datenverschlüsselung
+| Verschlüsselung || <code>aes256-gcm@openssh.com</code> || Datenverschlüsselung
 |-
-| MAC / Integrität || <code>hmac-sha2-256-etm</code> || Manipulation erkennen
+| Integrität || <code>hmac-sha2-256-etm</code> || Manipulation erkennen
 |-
 | Client-Schlüssel || <code>ed25519</code> || User Authentication

SSH Verbindungsaufbau: Unterschied zwischen den Versionen