SSH-Hostschlüssel auf Cloud-Macs prüfen und sicher rotieren

Wenn Entwickler zum ersten Mal eine Verbindung zu einem Cloud-Mac herstellen, fragt das Terminal üblicherweise, ob der unbekannte Host akzeptiert werden soll. Bei manuellen Verbindungen ist yes schnell eingegeben; in CI wirkt StrictHostKeyChecking=no noch bequemer. Beide Varianten umgehen jedoch die Identitätsprüfung. Sobald DNS, Adresskonfiguration oder Netzwerkpfad fehlgeleitet werden, können Zugangsdaten und Build-Artefakte auf dem falschen Rechner landen. Stattdessen sollte der Fingerabdruck des Hostschlüssels zunächst über ein vertrauenswürdiges Terminal ermittelt werden. Anschließend dürfen Entwicklungsrechner und automatisierte Jobs ausschließlich diesen Schlüssel akzeptieren.

Zunächst eine unabhängige Vertrauensbasis schaffen

Der Hostschlüssel weist nach, dass die aktuelle Verbindung tatsächlich zu dem erwarteten Mac führt. Er ist nicht mit dem privaten Schlüssel für die Benutzeranmeldung zu verwechseln. Beim Ed25519-Hostschlüssel lässt sich der Fingerabdruck beispielsweise über ein lokales Terminal auf dem Zielsystem auslesen. Dazu wird über das in der XcodeVM-Konsole bereitgestellte Web VNC ein Terminal geöffnet:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Der vollständige SHA256:-Wert muss zusammen mit der Instanzkennung, der Verbindungsadresse und dem verwendeten Abrufweg dokumentiert werden. Dieser Wert darf nicht ausschließlich über die SSH-Verbindung bezogen werden, die erst noch überprüft werden soll. Andernfalls entsteht ein Zirkelschluss bei der Verifikation.

Danach wird auf dem Entwicklungsrechner der aktuell vom entfernten Host angebotene öffentliche Schlüssel abgerufen:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > ~/.ssh/xcodevm_known_hosts.new
ssh-keygen -lf ~/.ssh/xcodevm_known_hosts.new -E sha256

Beide Fingerabdrücke müssen Zeichen für Zeichen übereinstimmen. Erst danach wird die Datei installiert:

install -m 600 ~/.ssh/xcodevm_known_hosts.new ~/.ssh/xcodevm_known_hosts
rm -f ~/.ssh/xcodevm_known_hosts.new

ssh-keyscan dient dazu, einen öffentlichen Schlüssel abzurufen, nicht dessen Vertrauenswürdigkeit nachzuweisen. Ohne einen unabhängig ermittelten Fingerabdruck als Referenz darf das Scanergebnis nicht direkt in eine produktive Vertrauensdatei übernommen werden.

known_hosts vom Projekt isolieren

Die globale Datei ~/.ssh/known_hosts eignet sich für alltägliche interaktive Verbindungen. Teamprojekte sollten jedoch eine separate Datei verwenden. So lassen sich Änderungen eindeutig prüfen, und das persönliche Bereinigen von Einträgen beeinträchtigt keine automatisierten Jobs.

In ~/.ssh/config wird dafür ein Alias eingerichtet:

Host xcodevm-build
    HostName 192.0.2.10
    User builder
    IdentityFile ~/.ssh/xcodevm_build_ed25519
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/xcodevm_known_hosts
    StrictHostKeyChecking yes
    HashKnownHosts yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

IdentitiesOnly yes verhindert, dass der Client nacheinander zu viele Identitätsdateien ausprobiert. Mit StrictHostKeyChecking yes schlagen Verbindungen bei unbekannten oder geänderten Schlüsseln sofort fehl. Vor dem Verbindungsaufbau sollte die aufgelöste Konfiguration geprüft werden, damit andere Regeln den Alias nicht überschreiben:

ssh -G xcodevm-build |
  grep -E '^(hostname|user|identityfile|userknownhostsfile|stricthostkeychecking) '

Werden innerhalb desselben Projekts mehrere Rechner verwendet, muss jeder Rechner einen eigenen Eintrag erhalten. Zusätzlich gehört die jeweilige Instanzkennung in das interne Änderungsprotokoll. Ein allgemeiner Alias, der auf eine zufällig wechselnde Adresse verweist, ist ungeeignet.

Fingerabdruck in CI fixieren

CI sollte die persönliche Vertrauensdatei eines Entwicklers nicht dauerhaft übernehmen. Robuster ist es, den erwarteten SHA256-Fingerabdruck als geschützte Variable zu hinterlegen. Jeder Job ruft den Schlüssel zunächst ab, vergleicht den Fingerabdruck und erstellt erst danach eine temporäre known_hosts-Datei.

set -euo pipefail

: "${MAC_HOST:?MAC_HOST is required}"
: "${EXPECTED_ED25519_SHA256:?fingerprint is required}"

scan_file="$(mktemp)"
known_hosts_file="$(mktemp)"
trap 'rm -f "$scan_file" "$known_hosts_file"' EXIT

ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > "$scan_file" 2>/dev/null
actual="$(ssh-keygen -lf "$scan_file" -E sha256 | awk '{print $2}')"

if [ "$actual" != "$EXPECTED_ED25519_SHA256" ]; then
  printf '%s
' "SSH host key verification failed" >&2
  exit 1
fi

install -m 600 "$scan_file" "$known_hosts_file"

ssh \
  -o UserKnownHostsFile="$known_hosts_file" \
  -o StrictHostKeyChecking=yes \
  -o IdentitiesOnly=yes \
  "$MAC_USER@$MAC_HOST" \
  'uname -m && sw_vers -productVersion'

Privater Schlüssel, erwarteter Fingerabdruck und Hostadresse sollten getrennt verwaltet werden. Zur Fehleranalyse darf der tatsächlich ermittelte Fingerabdruck im Protokoll erscheinen. Inhalte privater Schlüssel, Verbindungspasswörter oder nicht bereinigte Umgebungsvariablen dürfen dagegen nicht ausgegeben werden.

Schlüsseländerungen korrekt behandeln

Eine Änderung des Hostschlüssels kann durch ein Zurücksetzen des Systems, die Neuerzeugung der Hostschlüssel oder die Wiederverwendung einer Verbindungsadresse verursacht werden. Sie kann aber auch darauf hinweisen, dass die Verbindung zum falschen Ziel umgeleitet wurde. Erscheint REMOTE HOST IDENTIFICATION HAS CHANGED, müssen automatisierte Jobs zunächst angehalten werden. Den alten Eintrag einfach zu löschen und die Verbindung erneut zu versuchen, ist nicht zulässig.

Eine sichere Rotation erfolgt in dieser Reihenfolge:

1. In der Konsole prüfen, ob Instanzkennung, Verbindungsadresse und kürzlich ausgeführte Aktionen den Erwartungen entsprechen.
2. Den Ed25519-Fingerabdruck erneut über das lokale Terminal in Web VNC auslesen.
3. Eine zweite für die Wartung zuständige Person die alten und neuen Fingerabdrücke sowie den Änderungsgrund prüfen lassen.
4. Den öffentlichen Schlüssel des entfernten Hosts abrufen, den neuen Fingerabdruck verifizieren und eine neue Vertrauensdatei erzeugen.
5. Zunächst den Test-Job aktualisieren und eine schreibgeschützte Verbindung samt Umgebungsprüfung ausführen.
6. Anschließend die produktiven Jobs aktualisieren und den alten Fingerabdruck widerrufen.

Bei gehashten Einträgen lässt sich der alte Datensatz zunächst ermitteln:

ssh-keygen -F "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts
ssh-keygen -R "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts

Der zweite Befehl darf erst ausgeführt werden, nachdem der neue Fingerabdruck unabhängig bestätigt wurde. Das Löschen des alten Eintrags ist lediglich Teil der Rotation und ersetzt keine Verifikation.

Abnahme mit einer Checkliste abschließen

Vor der Inbetriebnahme sollten mindestens folgende Punkte geprüft werden:

Zusätzlich sollte ein Negativtest durchgeführt werden: Den erwarteten Fingerabdruck vorübergehend durch einen falschen Wert ersetzen und prüfen, ob der Job beendet wird, bevor ein entfernter Befehl tatsächlich ausgeführt wird. Danach wird der korrekte Wert wiederhergestellt. Anschließend sind ein schreibgeschützter Befehl, der Repository-Zugriff und der Build-Einstiegspunkt zu prüfen. Nur so ist belegt, dass die Schutzmaßnahme tatsächlich ausgeführt wird und nicht lediglich in einer Konfigurationsdatei steht.

Eine SSH-Vertrauenskette erfordert kein komplexes System. Entscheidend ist, die erstmalige Annahme und die erneute Verbindung nach einer Änderung von spontanen Bestätigungen in einen prüfbaren Prozess zu überführen. Das vertrauenswürdige Terminal liefert die Referenz, eine projektbezogene Datei speichert die feste Zuordnung, und CI prüft sie vor jeder Verbindung. Bei jeder Abweichung wird zunächst angehalten und verifiziert. Erst nach diesen Schritten verfügen Remote-Entwicklung und automatisierte Builds über dieselbe klar definierte Grenze für die Hostidentität.

Häufig gestellte Fragen