Interner Ablauf beim Verbindungsaufbau zwischen OpenSSH Server und Client

Damit sshd Verbindungsanforderungen von ssh entgegennehmen kann, muss für sshd folgende Voraussetzung erfüllt sein:

• Auf dem Rechner, auf dem sshd abläuft (Server-Rechner), existiert ein Host-Key (RSA, DSA, ECDSA oder Ed25519). Der Host-Key ist ein Schlüsselpaar bestehend aus einem privaten und einem öffentlichen Schlüssel und authentifiziert den Server-Rechner. Diese Voraussetzung ist durch die Installation in POSIX bereits erfüllt.

Bei jeder Verbindungsanforderung von ssh werden die folgenden Schritte ausgeführt:

1. sshd sendet den öffentlichen Teil seines Host-Key sowie eine Liste der von ihm unterstützten Verschlüsselungsalgorithmen an ssh. Als Verschlüsselungsverfahren kommen derzeit AES, ChaCha20 oder 3DES infrage.

2. ssh prüft, ob er sshd kennt, indem er nachschaut, ob zum jeweiligen System in der Datei $HOME/.ssh/known_hosts des Users bzw. in der vom Systemadministrator zentral bereitgestellten Datei /etc/ssh/ssh_known_hosts ein öffentlicher Schlüssel hinterlegt ist, und wenn ja, ob dieser mit dem vom sshd gesendeten Host-Key gleichen Typs (RSA/DSA/ECDSA/Ed25519) übereinstimmt:

   • Falls zum jeweiligen System ein öffentlicher Schlüssel hinterlegt ist und dieser identisch zu dem vom sshd gesendeten öffentlichen Host-Key ist, dann wird mit Schritt  3) fortgesetzt.

   • Falls ein Schlüssel hinterlegt ist, dieser aber nicht mit dem vom sshd gesendeten Host-Key identisch ist, dann kann das zwei Ursachen haben:

     1. Der Host-Key des sshd ist neu generiert worden (harmlose Variante).

     2. Es versucht gerade jemand einen aktiven „Man-in-the-Middle“-Angriff (MITM-Angriff) auf die SSH-Verbindung.

   Daher wird vom ssh in dieser Situation eine entsprechende Warnung ausgegeben und man sollte diese nur abweisen, wenn man sich hinreichend sicher ist, dass die Variante a) zutrifft.

   Wenn die Warnung abgewiesen wird, dann verfährt ssh wie bei nicht hinterlegtem Schlüssel.

   • Falls der Host-Key in diesen Dateien nicht enthalten ist, dann berechnet ssh aus dem vom sshd gesendeten öffentlichen Host-Key einen Fingerprint. Wenn ssh entsprechend konfiguriert ist (VerifyHostKeyDNS Yes), dann holt sich ssh den Host-Key-Fingerprint von DNS (falls dort gespeichert) und vergleicht ihn mit dem berechneten Fingerprint. Andernfalls zeigt ssh den berechneten Fingerprint an und fragt den Nutzer, ob dieser okay ist.

     • Stimmen die beiden Fingerprints nicht überein bzw. beantwortet der Nutzer die Frage mit "no", dann bricht ssh die Verbindung ab.

     • Bei Antwort "yes" trägt ssh den Host-Key in die Datei $HOME/.ssh/known_hosts ein, sodass er nachfolgend bekannt ist und ein Wechsel des Host-Keys, der ein Anzeichen für einen potenziellen MITM-Angriff sein kann, bemerkt wird. Dies gilt allerdings nur, wenn die Option StrictHostKeyChecking in der Konfigurationsdatei ssh_config nicht auf yes gesetzt wurde. Andernfalls muss man die Datei $HOME/.ssh/known_hosts manuell mit den korrekten Inhalten füllen. Eine ausführliche Beschreibung der Option StrictHostKeyChecking finden Sie auf den Man Pages von OpenSSH.

3. ssh und sshd tauschen diverse Daten aus. Mit diesen Dateien wird zum einen ein Diffie-Hellman-Schlüsselaustausch realisiert, um einen gemeinsamen Session Key zu erhalten. Zum anderen sendet sshd auch Daten, die er mit seinem privaten Host-Key signiert hat. Anhand dieser Signatur kann ssh feststellen, dass der sshd wirklich im Besitz des zum übermittelten öffentlichen Host-Key gehörenden privaten Host-Key ist.

4. Beide Seiten verwenden den Session Key für die Verschlüsselung der gesamten Kommunikation innerhalb der aktuellen Session. Der Rest der Session wird mithilfe eines symmetrischen Verschlüsselungsverfahrens verschlüsselt. Derzeit kommen AES, ChaCha20 oder 3DES infrage. ssh wählt den Verschlüsselungsalgorithmus aus der Liste aus, die ihm sshd zusammen mit dem Host-Key (siehe Schritt 1 ) mitgeliefert hat.

   Außerdem wird der Session Key für die Sicherstellung der Datenintegrität mittels eines MAC-Verfahrens (Message Authentication Code) verwendet, welches ssh ebenfalls aus einer in Schritt 1 vom sshd gelieferten Liste auswählt. Zu solchen Verfahren gehören HMAC-SHA2, HMAC-SHA1 oder UMAC in verschiedenen Ausprägungen.

5. Client und sshd führen nun einen Authentifizierungsdialog, in dem der Client gegenüber sshd seine Identität und Berechtigung nachweist.

   Näheres zur Client-Authentisierung finden Sie im Abschnitt „Authentifizierung zwischen OpenSSH Client und OpenSSH Server“.