SSH-Host-Keys und Machine-ID auf einem geklonten Linux-Host neu erzeugen

Ziel

Einem neu geklonten Linux-Host eigene, eindeutige SSH-Host-Keys und eine eigene Machine-ID geben und bestätigen, dass kein anderer Host der Flotte einen dieser beiden Werte teilt.

Voraussetzungen

Root-Zugriff auf dem Klon. Im Image sollten vor dem Klonen bereits die Host-Keys entfernt und /etc/machine-id geleert worden sein (ein separater Bereinigungsschritt), denn diese Methodik geht davon aus, dass diese Dateien fehlen oder leer sind und nicht die Werte der Referenzmaschine enthalten.

Schritte

1. Prüfen, ob bereits Host-Keys vorhanden sind: ls -l /etc/ssh/ssh_host_*. Existieren Dateien, die aus dem Referenz-Image übernommen und nicht bei diesem Boot erzeugt wurden, diese zuerst entfernen (rm -f /etc/ssh/ssh_host_*).
2. Einen frischen Satz erzeugen: ssh-keygen -A. Die Manpage beschreibt -A als Erzeugung von "host keys of all default key types (rsa, ecdsa, and ed25519) if they do not already exist" (Host-Keys aller Standardtypen, sofern sie noch nicht existieren), mit dem Standarddateipfad, leerer Passphrase und der Standard-Bitlänge je Typ. Bereits vorhandene Schlüsseltypen werden übersprungen. Erst das vorherige Entfernen der alten Keys (Schritt 1) sorgt also dafür, dass dieser scheinbar idempotente Befehl sie tatsächlich neu erzeugt.
3. Konfiguration prüfen und den SSH-Daemon neu starten, damit er die neuen Keys lädt: sshd -t && systemctl restart sshd unter RHEL/Fedora/SUSE, sshd -t && systemctl restart ssh unter Debian/Ubuntu (der Alias sshd existiert dort nur, solange die Unit aktiviert ist). Bestehende Sitzungen überstehen den Neustart. Clients, die den alten Key kennen, melden einen Host-Key-Konflikt und müssen ssh-keygen -R <host> ausführen.
4. Die Machine-ID prüfen: cat /etc/machine-id. Bei einem Klon eines korrekt geleerten Images hat systemd beim Booten eine neue ID erzeugt und gespeichert. systemd-machine-id-setup "may be used by system installer tools to initialize the machine ID" (kann von Installationswerkzeugen zur Initialisierung der Machine-ID verwendet werden); es wird nur aktiv, wenn die Datei fehlt oder leer ist, und übernimmt eine gültige ID aus /run/machine-id oder die D-Bus-Machine-ID, bevor es eine zufällige erzeugt. Auf einem laufenden Klon mit doppelter ID stattdessen einen frischen Wert schreiben: systemd-id128 new > /etc/machine-id (systemd 240+; andernfalls dbus-uuidgen > /etc/machine-id). /var/lib/dbus/machine-id als Symlink darauf anlegen, dann neu starten.
5. Eindeutigkeit über die Flotte hinweg prüfen: sha256sum /etc/ssh/ssh_host_ed25519_key.pub /etc/machine-id von jedem Host einsammeln (die Machine-ID hashen, da der Rohwert vertraulich ist), etwa per Konfigurationsmanagement oder einer einfachen SSH-Schleife, und bestätigen, dass keine zwei Hosts für einen der beiden Werte dasselbe Ergebnis liefern.

Erwartetes Ergebnis

Jeder Host hat eigene Host-Key-Fingerprints (für Clients sichtbar als abweichende Fingerprint-Abfrage beim ersten Verbindungsaufbau) und eine eigene, 32 Zeichen lange Machine-ID. Im Flotteninventar tauchen keine doppelten Werte auf.

Grenzen und Prüfbasis

ssh-keygen -A tut nichts mit einem Schlüsseltyp, für den bereits eine Datei vorhanden ist. Damit lässt sich eine Flotte nicht reparieren, in der Klone bereits kopierte Keys teilen; diese müssen zuerst gelöscht werden. Die Manpage zur Machine-ID hält fest, dass sie "must not be exposed in untrusted environments, in particular on the network" (nicht in nicht vertrauenswürdigen Umgebungen, insbesondere nicht im Netzwerk, offengelegt werden darf) und dass sie nicht direkt als stabile Kennung für andere Anwendungen verwendet werden darf. Braucht etwas eine Kennung pro Maschine, ist die Machine-ID mit einem anwendungsspezifischen Schlüssel zu hashen, statt sie unverändert preiszugeben. Die Neuerzeugung der Host-Keys erfordert keinen Reboot. Eine geänderte Machine-ID schon: journald, D-Bus und systemd-networkd lesen sie beim Start, und networkd leitet daraus seine Standard-DHCP-DUID ab.