Cybersicherheit

SSH-Hostschlüssel - Was die Warnung bei der ersten Verbindung wirklich schützt

Geschrieben von Adam Muiz Aktualisiert: 24 Aug 2026 9 Min. gelesen
SSH-Hostschlüssel - Was die Warnung bei der ersten Verbindung wirklich schützt

Die erste SSH-Verbindung zu einem Server hält häufig an, bevor ein Passwort abgefragt oder ein Benutzerschlüssel verwendet wird. Sie zeigt einen Fingerabdruck an und fragt, ob dem Host vertraut werden soll. Diese Abfrage lässt sich leicht als kleine Hürde behandeln: yes eingeben, fortfahren und sie vergessen. Doch welche Entscheidung wird in diesem Moment tatsächlich getroffen?

Die Frage lautet nicht, ob die Verbindung verschlüsselt wird. Es geht darum, ob der Rechner, der unter dieser Adresse antwortet, wirklich der Rechner ist, den wir erreichen wollten. Dieser Unterschied ist bei einem Heimserver ebenso wichtig wie in einem großen Netzwerk. Ein stark verschlüsseltes Gespräch mit einem Hochstapler bleibt ein Gespräch mit einem Hochstapler.

Eine SSH-Verbindung, zwei Vertrauensrichtungen

SSH führt üblicherweise zwei Authentifizierungen durch, die leicht verwechselt werden. Der Server authentifiziert sich gegenüber dem Client mit einem Hostschlüssel. Anschließend authentifiziert der Client den Benutzer gegenüber dem Server, etwa mit einem Passwort oder einem unter ~/.ssh/id_ed25519 gespeicherten Benutzerschlüssel. Die SSH-Protokollarchitektur in RFC 4251 ordnet die Serverauthentifizierung der Transportschicht und die Benutzerauthentifizierung einem separaten, darüberliegenden Protokoll zu.

Diese Prüfungen beantworten unterschiedliche Fragen:

  • Hostauthentifizierung: Ist dies der erwartete Server?
  • Benutzerauthentifizierung: Darf sich dieser Benutzer bei diesem Server anmelden?

Das Hinterlegen eines öffentlichen Benutzerschlüssels in authorized_keys beantwortet die erste Frage nicht. Ebenso gewährt das Erkennen des Hostschlüssels einem Benutzer keine Anmeldeberechtigung. Beide Richtungen sind wichtig.

Wofür der Fingerabdruck steht

Ein SSH-Server besitzt ein oder mehrere Hostschlüsselpaare. Der private Teil bleibt auf dem Server, während der öffentliche Teil Clients vorgelegt werden kann. Beim Schlüsselaustausch weist der Server nach, dass er den zugehörigen privaten Schlüssel kontrolliert. Ein Fingerabdruck ist eine kürzere Hash-Darstellung dieses öffentlichen Schlüssels und lässt sich leichter vergleichen als ein langer kodierter Schlüssel.

Aktuelles OpenSSH zeigt Fingerabdrücke laut seinem Handbuch zur Client-Konfiguration standardmäßig mit SHA-256 an. Ein übereinstimmender Fingerabdruck erlaubt eine präzise, aber begrenzte Schlussfolgerung: Der Endpunkt kann den privaten Schlüssel verwenden, der zum erwarteten öffentlichen Hostschlüssel gehört. Er beweist nicht, dass das Betriebssystem unkompromittiert ist, alle Dienste sicher konfiguriert sind oder die Person, die den Server betreibt, vertrauenswürdig ist.

Was noch fehlt, ist die Zuordnung zwischen einem Namen und einem Schlüssel. Die Kryptografie kann zeigen, dass derselbe private Schlüssel vorhanden ist. Der Client benötigt jedoch weiterhin einen vertrauenswürdigen Grund für die Annahme, dass dieser Schlüssel tatsächlich zu server.example.net gehört.

Die erste Verbindung hat ein Vertrauens-Bootstrap-Problem

Bei einer späteren Verbindung kann der SSH-Client den vorgelegten Schlüssel mit einem bereits gespeicherten Wert vergleichen. Bei der ersten Verbindung ist möglicherweise noch kein Wert vorhanden. Das ist ein Vertrauens-Bootstrap-Problem: Woher stammt der erste vertrauenswürdige Fingerabdruck?

RFC 4251 beschreibt eine praktische Strategie, die häufig Trust on First Use oder TOFU genannt wird: Bei der ersten Verbindung wird ein Hostschlüssel akzeptiert und lokal gespeichert; spätere unerwartete Änderungen werden abgelehnt oder gemeldet. Das ist nützlich, weil ein Angreifer erkannt werden kann, der erst nach der ersten vertrauenswürdigen Verbindung auftaucht. Die Methode allein kann jedoch keinen Angreifer erkennen, der sich bereits in die allererste ungeprüfte Verbindung eingeschaltet hat. Laut RFC kann eine solche Verbindung weiterhin vor passivem Mithören schützen, bleibt aber für einen aktiven Man-in-the-Middle-Angriff anfällig.

TOFU ist daher ein Kompromiss, weder bedeutungslos noch ein Beweis. In einem isolierten Netzwerk, dessen Pfad und Adressvergabe von einer einzigen Administration kontrolliert werden, kann dieser Kompromiss bewusst akzeptiert werden. In einem Flughafennetz, bei einem unbekannten Provider oder auf einem anderen Pfad, auf dem ein Abfangen plausibel ist, ist eine unabhängige Überprüfung wertvoller.

Ein besserer Ablauf für die erste Verbindung

Der erwartete Fingerabdruck sollte über einen Kanal bereitgestellt werden, der unabhängig von der geprüften SSH-Verbindung ist. Je nachdem, wer den Server kontrolliert, kann dies bedeuten:

  • den Fingerabdruck des Hostschlüssels direkt an der physischen Konsole oder der Provider-Konsole des Servers abzulesen;
  • die Administration über einen bereits authentifizierten Kommunikationskanal zu fragen; oder
  • die Fingerabdruckseite eines Betreibers über eine unabhängig vertrauenswürdige HTTPS-Verbindung zu prüfen.

Beispielsweise veröffentlicht GitHub seine SSH-Hostschlüssel-Fingerabdrücke, damit Benutzer sie mit dem vom SSH-Client angezeigten Wert vergleichen können. Entscheidend ist nicht der aktuelle Fingerabdruck von GitHub, der sich ändern kann, sondern die Trennung zwischen der SSH-Verbindung und dem Kanal, über den die erwartete Identität veröffentlicht wird.

An einer Serverkonsole kann eine Administration den Fingerabdruck des öffentlichen Ed25519-Hostschlüssels wie folgt anzeigen:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

sudo ist möglicherweise nicht erforderlich, wenn die öffentliche Datei lesbar ist. Entscheidend ist, den Befehl über eine bereits vertrauenswürdige Konsole oder einen administrativen Zugang auszuführen, nicht über genau jene ungeprüfte SSH-Sitzung, deren Identität infrage steht. Vor der Annahme sollten der vollständige Algorithmus und Fingerabdruck mit der Client-Abfrage verglichen werden.

Was known_hosts speichert

Nach der Annahme zeichnet OpenSSH die Zuordnung normalerweise in ~/.ssh/known_hosts auf. Das OpenSSH-Client-Handbuch erläutert, dass der Client diese Datenbank bei späteren Verbindungen prüft und warnt, wenn sich die Identität eines Hosts ändert. Eine Systemadministration kann außerdem eine systemweite Datei unter /etc/ssh/ssh_known_hosts verwalten.

Ein Eintrag lässt sich prüfen, ohne lange oder gehashte Zeilen manuell durchsuchen zu müssen:

ssh-keygen -F server.example.net

Für einen Dienst an einem nicht standardmäßigen Port wird die Schreibweise mit Host und Port in eckigen Klammern verwendet:

ssh-keygen -F '[server.example.net]:2222'

Das offizielle ssh-keygen-Handbuch dokumentiert -F zum Auffinden von Einträgen, einschließlich gehashter Hostnamen. Das Hashen der Namen in known_hosts kann die offengelegten Informationen reduzieren, falls die Datei kopiert wird. Die zugrunde liegende Entscheidung zur Hostauthentifizierung verändert es jedoch nicht.

Ein geänderter Schlüssel ist ein Signal, kein Urteil

Eine auffällige Warnung über einen geänderten Schlüssel soll die Verbindung unterbrechen. Sie kann auf einen Identitätsvortäuschungsversuch, eine Beeinflussung von DNS oder Routing oder einen anderen Pfad zum falschen Rechner hinweisen. Sie kann aber auch nach einer legitimen Neuinstallation, einem Serveraustausch, der Wiederherstellung eines Images oder einer beabsichtigten Rotation des Hostschlüssels erscheinen. Die Warnung allein kann nicht feststellen, welche Erklärung zutrifft.

Eine vorsichtige Reaktion ist eine kurze Untersuchung:

  1. Verbindung stoppen. Kein Passwort eingeben und keine sensiblen Befehle senden, solange die Identität ungeklärt ist.
  2. Ziel bestätigen. Hostname, IP-Adresse, Port, SSH-Konfigurationsalias und beteiligte Jump Hosts prüfen.
  3. Nach der Änderung fragen. Nach einer dokumentierten Neuerstellung oder Rotation suchen oder die Administration über einen separaten vertrauenswürdigen Kanal kontaktieren.
  4. Den neuen Fingerabdruck unabhängig beschaffen. Die vertrauenswürdige Konsole oder eine andere authentifizierte Quelle verwenden.
  5. Vor dem Ersetzen vergleichen. Die alte Zuordnung erst entfernen, wenn sowohl die neue Identität als auch der Grund für die Änderung plausibel sind.

Nach abgeschlossener Überprüfung kann OpenSSH den alten Eintrag auch bei einem gehashten Hostnamen sicher entfernen:

ssh-keygen -R server.example.net

Für einen eigenen Port:

ssh-keygen -R '[server.example.net]:2222'

-R zuerst auszuführen und erst danach nachzuforschen, kehrt den Sicherheitsmechanismus um. Die Warnung verschwindet, ohne dass geklärt wurde, weshalb sie erschien.

Warum ssh-keyscan keine Verifizierung ist

ssh-keyscan ist nützlich, um öffentliche Hostschlüssel zu erfassen, insbesondere bei der Vorbereitung einer Known-Hosts-Datei für viele Rechner:

ssh-keyscan server.example.net

Das Erfassen eines Schlüssels über denselben Netzwerkpfad authentifiziert ihn jedoch nicht. Das ssh-keyscan-Handbuch erklärt ausdrücklich, dass das Werkzeug die Echtheit der abgerufenen Schlüssel nicht prüfen kann. Ein Angreifer, der den Scan abfangen kann, könnte den Schlüssel ebenso austauschen wie bei einer ungeprüften SSH-Verbindung.

Damit ist das verbreitete Muster ssh-keyscan ... >> ~/.ssh/known_hosts als Sicherheits-Bootstrap unvollständig. Es automatisiert die Erfassung, nicht das Vertrauen. Der erfasste Schlüssel muss weiterhin unabhängig geprüft werden, sofern der Betreiber nicht bewusst ein Modell gewählt hat, in dem dieser Netzwerkpfad bereits als vertrauenswürdig gilt.

Automatisierung sollte eindeutig fehlschlagen

Interaktive Abfragen sind in Deployment-Jobs, Containern und geplanten Skripten unbequem. Das Abschalten der Prüfung kann eine Pipeline zum Laufen bringen, entfernt aber zugleich die Identitätsprüfung des Endpunkts, die diese Abfrage verursacht hat. Ein robusteres Muster besteht darin, vor dem Start des Jobs eine verifizierte known_hosts-Datei oder eine vertrauenswürdige Host-Zertifizierungsstelle bereitzustellen und unbekannte oder geänderte Identitäten eindeutig fehlschlagen zu lassen, statt sie stillschweigend zu akzeptieren.

In einem kleinen Heimlabor können einzeln hinterlegte Hostschlüssel verständlich und handhabbar sein. Für eine größere oder häufig neu aufgebaute Serverflotte beschreiben RFC 4251 und die OpenSSH-Handbücher ein anderes Modell: Eine Host-Zertifizierungsstelle wird als vertrauenswürdig hinterlegt, und Server legen von dieser CA signierte Hostzertifikate vor. Dadurch müssen Clients weniger einzelne Schlüssel hinterlegen, allerdings wird erhebliches Vertrauen auf die CA und ihre operative Sicherheit verlagert. Das ist eine alternative Architektur, kein kostenloses Upgrade.

Die Grenzen einer korrekten Übereinstimmung

Die Überprüfung des Hostschlüssels begrenzt ein bestimmtes Risiko: die Verbindung mit einem unerwarteten Endpunkt. Sie ersetzt weder Patches noch Zugriffskontrollen, den Schutz von Benutzerschlüsseln, Protokollierung oder sorgfältige Serveradministration. Sie macht auch einen kompromittierten Server nicht sicher; ein Angreifer, der den legitimen Server kontrolliert, kann möglicherweise dessen legitimen Hostschlüssel verwenden.

Hinzu kommt eine menschliche Grenze. Lange Fingerabdrücke werden leicht nur flüchtig verglichen, und auch ein unabhängiger Kanal kann kompromittiert sein. Das realistische Ziel ist keine perfekte Gewissheit durch eine einzelne Abfrage. Es geht darum, eine sinnvolle Identitätsprüfung nicht in einen gedankenlosen Reflex zu verwandeln.

Fazit

Die SSH-Fingerabdruckabfrage stellt eine bescheidene, aber wesentliche Frage: Welchem Server wollen wir gleich vertrauen? Bei der ersten Verbindung entsteht die stärkste Antwort durch den Vergleich des Fingerabdrucks über einen unabhängigen Kanal. Bei späteren Verbindungen macht known_hosts aus dieser anfänglichen Entscheidung eine Kontinuitätsprüfung.

Wenn sich ein Schlüssel ändert, sind weder Panik noch automatisches Löschen eine gute Diagnose. Die Verbindung sollte gestoppt, das Ziel und der Grund geprüft und der neue Fingerabdruck separat beschafft werden. Erst dann wird der gespeicherte Eintrag aktualisiert. Diese kurze Pause bewahrt den Teil von SSH, den Verschlüsselung allein nicht liefern kann: Vertrauen darin, wer sich am anderen Ende befindet.

References