Aktuelle Version vom 21. Juli 2026, 08:59 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 (KEX, Host-Key, Cipher, Hash, MAC)
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 sendet seinen öffentlichen DH-Wert
Server berechnet daraus den KEX-Hash (H) und signiert ihn mit seinem privaten Host Key
Server sendet seinen eigenen DH-Wert zusammen mit dieser Signatur zurück
Client prüft die Signatur anhand des öffentlichen Host Keys – damit ist bewiesen, dass der Server wirklich der Besitzer des Host Keys ist
Beide Seiten berechnen daraus unabhängig denselben Session Key
Der Session Key wird nie übertragen
Ein Lauscher kann den Session Key nicht ableiten

Ab jetzt alles verschlüsselt

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

Phase 2: User Authentication

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

Ablauf Public-Key-Authentifizierung

Client schickt: Username, Methode publickey und welchen öffentlichen Schlüssel er verwenden will
Server prüft, ob dieser Schlüssel in ~/.ssh/authorized_keys steht
Wenn nein → Auth fail
Client signiert das Transscript der gemeinsamen Verbindungsdaten und schickt die Signatur zum Server
Server hat die gemeinsamen Verbindungsdaten auch präsent und er entschlüsselt die Signatur vom Client.
Wenn das Ergebnis der Entschlüsselung mit den eigenen gesammelten Verbindungsdaten übereinstimmt.
Ist die Authentifizierung erfolgreich.

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

Ablauf Password-Authentifizierung

Client schickt: Username, Methode password
Client schickt Username und Passwort (verschlüsselt übertragen)
Server prüft das Passwort → Auth OK oder Auth fail

Einfacher, aber weniger sicher als Public-Key-Authentifizierung
Anfällig für Brute-Force-Angriffe

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 14: / Zeile 14: @@
 * '''Phase 3 – Session Phase:''' Die eigentliche Arbeit beginnt – Befehle, Dateiübertragungen, Tunnel usw.
-{#drawio:ssh-verbindung-1}
+[[Datei:Ssh-verbindung-1.png|800px]]
 <!-- ===================================================== -->
 <!-- GRAFIK HIER: Einstiegs-Diagramm (Password-Variante)   -->
@@ Zeile 62: / Zeile 64: @@
 * Server prüft: ''Wer will sich einloggen – und hat diese Person Berechtigung?''
 * Sicherste Methode: '''Public-Key-Authentifizierung'''
+[[Datei:Ssh-verbindung-2.png|600px]]
 <!-- ===================================================== -->
 <!-- GRAFIK HIER: Vollständiges Diagramm (Public-Key)      -->
@@ Zeile 74: / Zeile 76: @@
 # Server prüft, ob dieser Schlüssel in <code>~/.ssh/authorized_keys</code> steht
 # Wenn nein → Auth fail
-# Wenn ja → Server schickt eine Challenge (Zufallsdaten)
+# Client signiert das Transscript der gemeinsamen Verbindungsdaten und schickt die Signatur zum  Server
-# Client signiert die Challenge mit seinem '''privaten''' Schlüssel und schickt die Signatur zurück
+# Server hat die gemeinsamen Verbindungsdaten auch präsent und er entschlüsselt die Signatur vom Client.
-# Server prüft die Signatur mit dem öffentlichen Schlüssel → Erfolg
+# Wenn das Ergebnis der Entschlüsselung mit den eigenen gesammelten Verbindungsdaten übereinstimmt.
+# Ist die Authentifizierung erfolgreich.
 * Der private Schlüssel verlässt nie den eigenen Rechner
 * Sicherer als ein Passwort, weil die Signatur ohne privaten Schlüssel nicht reproduzierbar ist

SSH Verbindungsaufbau: Unterschied zwischen den Versionen