Summary

  • RFC 4251 beschreibt eine lokale Zuordnung von Rechnernamen und öffentlichen Hostschlüsseln. Nach dem ersten Kontakt wird jeder weitere Schlüssel mit dem gespeicherten Eintrag verglichen.
  • OpenSSH führt diese Erinnerung in known_hosts. Neue Schlüssel können zur Bestätigung vorgelegt, geänderte Schlüssel bekannter Rechner abgewiesen werden. Ein bereits authentifizierter Server kann weitere Schlüssel vor einem Wechsel mitteilen.

Bei der SSH-Verbindung weist sich der Server mit einem Hostschlüssel aus. Damit der Client wirklich den gewünschten Rechner erkennt, braucht er eine verlässliche Verbindung zwischen Rechnernamen und Schlüssel. RFC 4251 vom Januar 2006 beschreibt zwei Wege: eine lokale Datenbank oder eine vertrauenswürdige Zertifizierungsstelle. Die lokale Variante benötigt keine zentrale Stelle, die jeden Server vorher kennt. Jemand muss trotzdem den ersten Eintrag verantworten.

Der Standard schildert eine pragmatische Praxis: Den ersten Schlüssel annehmen, speichern und bei späteren Verbindungen vergleichen. Das Rechnergedächtnis wächst mit jeder Begegnung. Wer den allerersten Kontakt abfängt, kann allerdings seinen eigenen Schlüssel unterschieben. Deshalb nennt der RFC die Prüfung eines Fingerabdrucks über einen unabhängigen Kommunikationsweg. Wird der richtige Schlüssel notiert, fällt ein späterer Austausch auf, auch wenn der Name über der Tür gleich bleibt.

Bei OpenSSH liegt das Gedächtnis in ~/.ssh/known_hosts. Das OpenBSD-Handbuch zu ssh(1) beschreibt die gespeicherten Hostschlüssel und die deutliche Warnung bei einer Änderung. Die Warnung liefert keinen fertigen Kriminalfall. Ein Administrator kann den Rechner neu aufgesetzt oder seinen Schlüssel planmäßig getauscht haben; ein Angreifer kann ebenfalls einen anderen Schlüssel präsentieren. Der Client kennt zunächst nur den Widerspruch zwischen damals und heute. Genau den lässt er nicht geräuschlos verschwinden.

Wie streng die erste Vorstellung abläuft, zeigt das Handbuch ssh_config(5). StrictHostKeyChecking=ask fragt vor der Aufnahme eines neuen Rechners und lehnt geänderte Schlüssel bekannter Rechner ab. accept-new übernimmt neue Schlüssel automatisch, verweigert aber ebenfalls geänderte. Bei yes müssen neue Schlüssel von Hand eingetragen werden. Diese Varianten regeln den Eintritt; sie nehmen der alten Bekanntschaft nicht ihr Gedächtnis.

Auch ein legitimer Schlüsselwechsel lässt sich vorbereiten. Mit UpdateHostKeys darf ein bereits authentifizierter Server weitere Hostschlüssel bekannt geben. Solange der alte Schlüssel die Verbindung noch glaubwürdig macht, kann der Client den neuen aufnehmen. Der Nachfolger bekommt eine Vorstellung durch jemanden, den die Datei bereits kennt.

Das Werkzeug ssh-keyscan sammelt öffentliche Hostschlüssel und gibt sie passend für known_hosts aus. Seine Anleitung sagt ausdrücklich, dass ein Scan die Echtheit der gesammelten Schlüssel nicht belegt. Ein Angreifer im Netz kann selbst Schlüssel liefern. Die bequem gefüllte Akte ist nur dann etwas wert, wenn der erste Eintrag aus einer überprüften Begegnung stammt. Danach erinnert sie sich erstaunlich lange.