SSH Verbindungsaufbau

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

1. Client schickt: Username, Methode publickey und welchen öffentlichen Schlüssel er verwenden will
2. Server prüft, ob dieser Schlüssel in ~/.ssh/authorized_keys steht
3. Wenn nein → Auth fail
4. Wenn ja → Server schickt eine Challenge (Zufallsdaten)
5. Client signiert die Challenge mit seinem privaten Schlüssel und schickt die Signatur zurück
6. Server prüft die Signatur mit dem öffentlichen Schlüssel → 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

Ablauf Password-Authentifizierung

1. Client schickt: Username, Methode password
2. Client schickt Username und Passwort (verschlüsselt übertragen)
3. 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