Rechner auf denen der OpenSSH-Daemon läuft, haben ein oder mehrere Host-Keys. Diese sind standardmäßig unter /etc/ssh zu finden und haben den Präfix „ssh_host_“, gefolgt vom Typ des Keys (z.B. rsa oder ed25519) und dem Postfix „_key“ (Private-Key) bzw. „_key.pub“ (Public-Key). Damit der lokale Rechner einen Ziel-Rechner mit SSH-Daemon authentifizieren kann, benötigt er einen gültigen Public-Key dieses Ziel-Rechners. Die dem lokalen Rechner bekannten Ziel-Rechner sind in einer sogenannten Known-Hosts Datei hinterlegt (typischerweise ~/.ssh/known_hosts und /etc/ssh/ssh_known_hosts).

Bei der ersten SSH-Verbindung zu einem neuen oder unbekannten Rechner ist der Public-Key dieses Ziel-Rechners nicht bekannt und wird daher auch nicht in einer lokalen Known-Hosts Datei gefunden:

user01@client01 $ ssh-keygen -F server01
user01@client01 $

Der lokale Rechner kann den Ziel-Rechner also nicht authentifizieren:

user01@client01 $ ssh server01
The authenticity of host 'server01 (10.33.16.11)' can't be established.
RSA key fingerprint is SHA256:Gpkf/1w9PubqXD22+vi9t2l56ERk1DfQrSl/L3lq8/M.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Es erfolgt eine Warnung (“authenticiy of host … can’t be establiched“), der Fingerprint des Public-Keys des Ziel-Rechners wird angezeigt („key fingerprint is SHA256:Gpkf/1w9PubqXD22+vi9t2l56ERk1DfQrSl/L3lq8/M“) und es wird eine Bestätigung eingeholt fortzufahren („Are you sure you want to continue connecting”).

An dieser Stelle müsste der Benutzer den angezeigten Key überprüfen und nur wenn dieser tatsächlich von dem Ziel-System stammt akzeptieren. Der Fingerprint wird dann in die Known-Hosts Datei des Benutzers eingetragen und das Ziel-System ist ab dann bekannt:

user01@client01 $ ssh-keygen -F server01
# Host server01 found: line 4
server01 ssh-rsa AAAAB3NzaC1yd3EAAAADAQABAAABAQCjMKwutKaEEdKc3Cth7fNkv5yh2TArrCcVpCZG+1okGr1nPqkP9frYJW+HsXpMWH7PL1JTSzECVg2Pn34DeNlK9fPcxSECRJ4WVWYEMESwMytiZ5nW1Xq214hezvMV9xK7Li/PXzn+r29pezP9d4EEu6Pywd1Pdv53qDt/DdWG1GHr1eILeBIFYqv79t4echufGAOj8DY1h4/fCkaMor3y1NgnsSmAgfiNYoHs+1FfrMM+ogiLW0rRyPURZyJi78WnZB06lrLEPnONrRoVvtSNcGLl9ZkMP6fPhK17FGC4Q4uecgf20aOUh01ZUfybD0efNhrBaPsgFHsi9L4sKFMb
user01@client01 $

Das Prinzip dahinter ist TOFU (trust on first use): bei der ersten Benutzung wird das Vertrauen für alle zukünftigen Nutzungen aufgebaut. Das Problem dabei ist, das die Benutzer den angezeigten Fingerprint typischerweise nicht überprüfen und die Abfrage einfach immer mit „yes“ akzeptieren. Dies ermöglicht einen Man-in-the-Middle Angriff, bei dem ein Zwischensystem sich für das Ziel-System ausgibt. In Umgebungen mit hunderten oder tausenden von Systemen dürfte es auch ziemlich schwierig sein, jeweils bei der ersten Verbindung den angezeigten Fingerprint zu überprüfen, selbst wenn man z.B. Listen mit den gültigen Fingerprints der Public-Keys besitzt.

Die Verwendung von SSH Host-Zertifikaten löst dieses Problem.