Beim Erzeugen des SSH Host-Zertifikats hatten wir das Zertifikat schon auf die Verwendung für einen Rechner beschränkt. Wir hatten dazu die bekannten Hostnamen und die IP-Adresse mit der Option „-n“ angegeben, dies aber nicht weiter erläutert. Dies soll an dieser Stelle nachgeholt werden.

SSH Zertifikate können in ihrer Verwendung auf eine Menge von sogenannten Prinicipals beschränkt werden. Für SSH Host-Zertifikate können dies Hostnamen und/oder IP-Adressen sein. Die Angabe von Principals ist optional. Ein SSH Host-Zertifikat ohne Principals kann von jedem Rechner verwendet werden, vorausgesetzt dieser besitzt den zugehörigen Private-Host-Key. Wir zeigen dies an einem kleinen Beispiel:

Als erstes Erzeugen wir für den Rechner server01 ein SSH Host-Zertifikat ohne Angabe von Principals (siehe SSH-Server: Erzeugen von SSH Host-Zertifikaten):

root@ca-host # ssh-keygen -I server01.powercampus.de -s /etc/security/ssh-ca/ssh_host_ca_key -h /tmp/ssh_host_ed25519_key.pub
Enter passphrase for "/etc/security/ssh-ca/ssh_host_ca_key": XXXXXXXXXX
Signed host key /tmp/ssh_host_ed25519_key-cert.pub: id "server01.powercampus.de" serial 0 valid forever
root@ca-host #

Das SSH Host-Zertifikat kopieren wir auf den Server server01 und tragen dieses auch in /etc/ssh/sshd_config ein (Keyword HostCertificate). Anschließend starten wir auf dem Server den sshd-Daemon durch. Einen eventuell vorhandenen Known-Hosts Eintrag auf dem Client entfernen wir:

user01@client01 $ ssh-keygen -R server01
# Host server01 found: line 5
/home/user01/.ssh/known_hosts updated.
Original contents retained as /home/user01/.ssh/known_hosts.old
user01@client01 $ 

Auf dem Client ist die Host CA in /etc/ssh/ssh_known_hosts oder ~/.ssh/known_hosts eingetragen (siehe: SSH-Client: Einrichten der Host-Key Überprüfung mit dem Public-Key der Host-Zertifizierungsstelle).

Ein Login mit SSH funktioniert aufgrund des vorhandenen Zertifikats wie erwartet ohne einmalige Bestätigung (TOFU) des Host-Keys:

user01@client01 $ ssh server01
Last login: Sun Jan 18 11:08:05 2026 on /dev/pts/0 from 192.168.55.44
user01@client01 $

Weder im Private-Key, dem Public-Key oder dem Zertifikat des Servers steht die ID des Servers. Daher lässt sich diese auch so nicht überprüfen. Verwendet man den Private-Key und das Zertifikat ohne Principal auf einem anderen Server, dann wird dieser Server automatisch, ohne weitere Meldungen oder nachfragen akzeptiert. Daher sollten Host-Zertifikate unbedingt Hostnamen und/oder IP-Adressen als Principals enthalten!

Um zu demonstrieren das ein Zertifikat in der Verwendung beschränkt werden kann, erzeugen wir das Zertifikat für den Server server01 neu, geben aber dieses Mal als Principal den Hostnamen eines anderen Servers (hier server02) an:

root@ca-host # ssh-keygen -I server01.powercampus.de -s /etc/security/ssh-ca/ssh_host_ca_key -h -n server02 /tmp/ssh_host_ed25519_key.pub
Enter passphrase for "/etc/security/ssh-ca/ssh_host_ca_key": XXXXXXXXXX
Signed host key /tmp/ssh_host_ed25519_key-cert.pub: id "server01.powercampus.de" serial 0 for server02 valid forever
root@ca-host #

Wir kopieren dieses Zertifikat wieder auf server01 und restarten sshd.

Dann versuchen wir wieder einen Login mit SSH auf das System server01:

user01@client01 $ ssh server01
Certificate invalid: name is not a listed principal
The authenticity of host 'server01 (10.33.16.11)' can't be established.
ED25519 key fingerprint is SHA256:kaIQuZjLc0sLh52GuBOJYHMycpmv/frARAyejq+koOA.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.
user01@client01 $

Jetzt kommt als erstes der Hinweis das das Zertifikat für die Verwendung durch den Server nicht gültig ist („Certificate invalid: name is not a listed principal“). Es wird die Warnung ausgegeben das der Ziel-Rechner nicht authentifiziert werden kann („The authenticity of host ’server01 (10.33.16.11)‘ can’t be established.“) und der Benutzer wird gefragt wie es weitergehen soll. Wir haben an dieser Stelle entschieden das der Ziel-Rechner nicht vertrauenswürdig ist und haben die Verbindung beendet!

Durch die Verwendung von Principals in SSH Host-Zertifikaten wird also eine falsche Identität eines Ziel-Rechners erkannt und eine eindeutige Warnung ausgegeben. Man kann aber weiterhin, wie bisher, den Host-Key bestätigen und mit dem Login fortfahren. Dies kann über eine der beiden folgenden Möglichkeiten, die wir später anschauen, verhindert werden:

• • StrictHostKeyChecking=yes verwenden: ist der Public-Key des Ziel-Systems nicht bekannt und besitzt das Ziel-System kein gültiges Zertifikat, wird die Verbindung nicht erlaubt.
  • Die erlaubten HostKeyAlgorithms auf Algorithmen mit Zertifkaten einschränken.

Alle SSH Host-Keys sollten immer mit Angabe von Principals erzeugt werden!