Thomas.will: Die Seite wurde neu angelegt: „= SSH-Verbindungsaufbau = SSH baut eine Verbindung in drei aufeinanderfolgenden Phasen auf. Dieser Artikel erklärt, was dabei Schritt für Schritt im Hinterg…“

2026-04-11T12:04:06Z

Die Seite wurde neu angelegt: „= SSH-Verbindungsaufbau = SSH baut eine Verbindung in drei aufeinanderfolgenden Phasen auf. Dieser Artikel erklärt, was dabei Schritt für Schritt im Hinterg…“

Neue Seite

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

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

== 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 ==

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:

* '''KEX-Algorithmen:''' Verfahren für den Schlüsselaustausch (z. B. <code>curve25519-sha256</code>)
* '''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.

=== Host-Key-Prüfung ===

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?''

SSH überprüft das mithilfe der Datei <code>~/.ssh/known_hosts</code>. Dort werden beim ersten Verbindungsaufbau die Fingerabdrücke bekannter Server gespeichert.

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

=== 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'''.

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.

Ablauf im Detail:

# Client erzeugt ein zufälliges privates Geheimnis und berechnet daraus einen '''Public Value'''
# 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 ===

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.

== Phase 2: User Authentication (Public Key) ==

Der Kanal ist jetzt verschlüsselt. Jetzt muss der Server wissen: ''Wer will sich hier einloggen – und hat diese Person die Berechtigung?''

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.

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"
! Channel-Typ !! Verwendung !! Beispiel
|-
| <code>shell</code> || Interaktive Terminal-Sitzung || <code>ssh user@server</code>
|-
| <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>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.

== Häufige Fehlermeldungen ==

=== Host-Key-Warnung ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

'''Ursache:''' Der Host Key des Servers hat sich geändert (z. B. nach Neuinstallation des Servers).

'''Lösung:''' Den alten Eintrag aus <code>~/.ssh/known_hosts</code> entfernen:
ssh-keygen -R server.example.com

=== Permission denied (publickey) ===

Permission denied (publickey).

'''Ursache:''' Der öffentliche Schlüssel ist nicht in <code>~/.ssh/authorized_keys</code> des Servers eingetragen, oder die Dateiberechtigungen stimmen nicht.

'''Lösung:'''
ssh-copy-id user@server

Berechtigungen auf dem Server prüfen:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

== Verwendete Algorithmen ==

{| class="wikitable"
! Kategorie !! Moderne Empfehlung !! Zweck
|-
| Key Exchange (KEX) || <code>curve25519-sha256</code> || Gemeinsamen Session Key ableiten
|-
| Host Key || <code>ssh-ed25519</code> || Server-Identität beweisen
|-
| Symmetrische Verschlüsselung || <code>aes256-gcm@openssh.com</code> || Datenverschlüsselung
|-
| MAC / Integrität || <code>hmac-sha2-256-etm</code> || Manipulation erkennen
|-
| Client-Schlüssel || <code>ed25519</code> || 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 ==

* [https://www.openssh.com/ openssh.com] – Offizielle OpenSSH-Website
* [https://datatracker.ietf.org/doc/html/rfc4251 RFC 4251] – SSH Protocol Architecture
* [https://datatracker.ietf.org/doc/html/rfc4252 RFC 4252] – SSH Authentication Protocol

[[Kategorie:Netzwerk]]
[[Kategorie:Sicherheit]]
[[Kategorie:Kryptographie]]
[[Kategorie:SSH]]

SSH Verbindungsaufbau - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „= SSH-Verbindungsaufbau = SSH baut eine Verbindung in drei aufeinanderfolgenden Phasen auf. Dieser Artikel erklärt, was dabei Schritt für Schritt im Hinterg…“