Under Construction
Gültigkeitszeitraum von SSH Host-Zertifikaten beschränken
Standardmäßig sind SSH Host-Zertifikate unbeschränkt gültig. Das führt zu einer Reihe von Problemen:
- SSH Host-Zertifikate und zugehörige Private Host-Keys mit veralteten und unsicheren Algorithmen können zeitlich unbefristet verwendet werden.
- Ein gestohlener Host-Key mit zugehörigem Zertifikat kann zeitlich unbeschränkt von einem Angreifer verwendet werden, z.B. für Man-in-the-Middle Angriffe.
- Kompromitierte Zertifikate müssen über komplexe Sperrlisten verwaltet werden.
Beim Erzeugen von SSH Zertifikaten kann ein Gültigkeitszeitraum für das Zertifikat angegeben werden. Solche Zertifikate verlieren ihre Gültigkeit nach Ablauf dieses Zeitraums. Die Vorteile von ablaufenden Zertifikaten sind unter Anderem die folgenden:
- Ablaufende Zertifikate zwingen zur regelmäßigen Rotation der Zertifikate, dabei sollten am Besten dann auch die Host-Keys rotiert werden.
- Zertifikate mit kurzen Laufzeiten erfordern in der Regel kein Widerrufen der Zertifikate, da diese ohnehin Ausaltern.
- Ein gestohlener Host-Key mit zugehörigem ablaufenden Zertifikat kann nur ein beschränkte Zeit von einem Angreifer verwendet werden.
Hinweis: Die Verwendung von Principals in SSH Host-Zertifikaten erschwert für einen Angreifer das Verwenden gestohlener Host-Keys mit Zertifikat, da im Zertifikat die erlaubten Hostnamen und IPs für das Zertifikat enthalten sind.
Bei der Erstellung eines SSH Host-Zertifikats mit ssh-keygen kann über die Option „-V“ (validity interval) ein Gültigkeitszeitraum für das Zertifikat angegeben werden:
end_time – das Zertifikat ist ab sofort bis zum angegebenen End-Zeitpunkt gültig.
start_time:end_time – das Zertifikat ist ab dem angegebenen Start-Zeitpunkt bis zum End-Zeitpunkt gültig.
Die Zeitpunkte können in einem der folgenden Format angegeben werden:
always – das Zertifikat hat keinen Start-Zeitpunkt
YYYYMMDD[-DDHHMM[SS]] – Datum und Uhrzeit des Zeitpunkts in der Zeitzone des Systems
YYYYMMDD[-DDHHMM[SS]]Z – Datum und Uhrzeit des Zeitpunkts in der Zeitzone UTC
-relative_time – relative Zeit vor dem aktuellen Zeitpunkt (z.B. -5w: vor 5 Wochen)
0xseconds_since_epoch – Zahl der Sekunden seit 01.01.1970 00:00:00 UTC als hexadezimale Zahl
forever – das Zertifikat hat keinen End-Zeitpunkt und ist daher unbeschränkt gültig.
+relative_time – relative Zeit ab dem aktuellen Zeitpunkt (z.B. +4m: für 4 Monate)
Wir demonstrieren dies, indem wir ein Zertifikat für unseren Server server01 erzeugen, welches nur 10 Minuten gültig ist (ab dem Zeitpunkt der Erzeugung):
root@ca-host # date
Sun Jan 18 18:41:52 CET 2026
root@ca-host # ssh-keygen -I server01.powercampus.de -s /etc/security/ssh-ca/ssh_host_ca_key -h -n server01 -V +10m /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 server01 valid from 2026-01-18T18:40:00 to 2026-01-18T18:51:54
root@ca-host #
Wir schauen kurz in das Zertifikat:
root@ca-host # date
Sun Jan 18 18:42:04 CET 2026
root@ca-host # ssh-keygen -L -f /tmp/ssh_host_ed25519_key-cert.pub
/tmp/ssh_host_ed25519_key-cert.pub:
Type: ssh-ed25519-cert-v01@openssh.com host certificate
Public key: ED25519-CERT SHA256:kaIQuZjLc0sLh52GuBOJYHMycpmv/frARAyejq+koOA
Signing CA: ED25519 SHA256:sFGHnY5BV/814NzyJU0Awv4Z2OSZzwQiSUr8C81qNJ0 (using ssh-ed25519)
Key ID: "server01.powercampus.de"
Serial: 0
Valid: from 2026-01-18T18:40:00 to 2026-01-18T18:51:54
Principals:
server01
Critical Options: (none)
Extensions: (none)
root@ca-host #
Die aktuelle Zeit ist 18:42:04. Das Zertifikat läuft um 18:51:54 Sekunden ab!
Wir kopieren dieses Zertifikat auf den Server server01 und aktivieren dieses durch Restart des sshd. Dann testen wir mit einem Login vor 18:51:54:
user01@client01 $ date
Sun Jan 18 18:46:45 CET 2026
user01@client01 $ ssh server01
Last unsuccessful login: Sun Jan 18 11:44:35 2026 on ssh from 192.168.55.31
Last login: Sun Jan 18 18:45:43 2026 on /dev/pts/0 from 192.168.55.44
user01@client01 $
Der Login um 18:46:45 ist erfolgreich. Das SSH Host-Zertifikat auf dem Server server01 hat sein Ablaufdatum noch nicht erreicht. Wir loggen uns wieder aus und warten ein paar Minuten, bevor wir dann erneut einen Login versuchen:
user01@client01 $ date
Sun Jan 18 18:53:51 CET 2026
user01@client01 $ ssh server01
Certificate invalid: expired
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 $
Es wird eine Meldung ausgegeben, die darauf hinweist das das verwendete Host-Zertifikat abgelaufen ist („Certificate invalid: expired“). Das Ziel-System ist nicht bekannt („The authenticity of host ’server01 (10.33.16.11)‘ can’t be established”). Der Benutzer wird aufgefordert zu entscheiden wie er fortfahren möchte. Aufgrund des abgelaufenen Zertifikats haben wir uns entschieden die Verbindung zu beenden. Da kein StrictHostKeyChecking aktiviert ist, kann der Benutzer aber trotzdem entscheiden den Public-Host-Key zu akzeptieren und die Verbindung zuzulassen! Wird StrictHostKeyChecking verwendet, dann ist dies nicht möglich, wie hier gezeigt durch Verwenden der Option „-o stricthostkeychecking=yes“:
user01@client01 $ ssh -o stricthostkeychecking=yes server01
Certificate invalid: expired
No ED25519 host key is known for server01 and you have requested strict checking.
Host key verification failed.
user01@client01 $
Dies kann in der SSH-Konfiguration hinterlegt werden, siehe …
Es ist ratsam alle SSH Host-Zertifikate mit einem Ablaufdatum zu erzeugen. Wie lange die maximale Gültigkeitsdauer sein sollte, hängt stark von der Umgebung und der Verwendung des Systems ab. Besteht eine Umgebung aus einer größeren Anzahl von Systemen, hängt die maximale Gültigkeitsdauer auch vom Grad der Automatisierung ab, da man manuell nicht in kurzen Zeitabständen tausende von Host-Zertifikaten tauschen kann.
