SSH Verbindungsaufbau

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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. curve25519-sha256)
  • Host-Key-Algorithmen: Wie der Server sich ausweisen kann (z. B. ssh-ed25519)
  • Cipher-Algorithmen: Verschlüsselungsverfahren (z. B. aes256-gcm)
  • MAC-Algorithmen: Methoden zur Integritätsprüfung (z. B. hmac-sha2-256)

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 ~/.ssh/known_hosts. Dort werden beim ersten Verbindungsaufbau die Fingerabdrücke bekannter Server gespeichert.

Warnung: Wenn SSH die Meldung WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 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:

  1. Client erzeugt ein zufälliges privates Geheimnis und berechnet daraus einen Public Value
  2. Server macht dasselbe und schickt seinen Public Value sowie eine Signatur (erstellt mit dem privaten Host Key)
  3. Client prüft die Signatur mit dem öffentlichen Host Key des Servers → bestätigt die Serveridentität
  4. 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:

  1. Client schickt einen Auth Request mit Benutzername, Methode „publickey" und dem verwendeten öffentlichen Schlüssel
  2. Server prüft: Ist dieser Public Key in ~/.ssh/authorized_keys eingetragen?
  3. Wenn ja: Server schickt eine Challenge (verschlüsselte Zufallsdaten)
  4. Client signiert die Challenge mit seinem privaten Schlüssel und sendet die Signatur zurück
  5. 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.

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 per SFTP sftp user@server
direct-tcpip Port-Forwarding / Tunnel ssh -L 8080:localhost:80 user@server

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 ~/.ssh/known_hosts entfernen: 

ssh-keygen -R server.example.com

Permission denied (publickey)

Permission denied (publickey).

Ursache: Der öffentliche Schlüssel ist nicht in ~/.ssh/authorized_keys 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

Kategorie Moderne Empfehlung Zweck
Key Exchange (KEX) curve25519-sha256 Gemeinsamen Session Key ableiten
Host Key ssh-ed25519 Server-Identität beweisen
Symmetrische Verschlüsselung aes256-gcm@openssh.com Datenverschlüsselung
MAC / 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

Abgerufen von „http://wiki.ixheim.de/index.php?title=SSH_Verbindungsaufbau&oldid=68497“