SSH-Anmeldungen, signiert von step-ca: Schluss mit authorized_keys

Warum Zertifikate statt Schlüssel

SSH vertraut beim ersten Kontakt. Verbinde dich mit einer neuen Maschine, und sie zeigt dir einen Fingerabdruck und fragt, ob du sicher bist. Niemand prüft das. Alle tippen yes. Es ist dieselbe Gewohnheit wie das Wegklicken einer Browserwarnung, und genau das braucht eine Maschine in der Mitte von dir.

Die andere Richtung ist nicht besser. Jeder Server führt eine authorized_keys-Datei pro Benutzer, und jede davon wächst. Schlüssel kommen dazu und werden nie entfernt. Jemand geht, und sein Schlüssel bleibt auf einer Kiste, an die sich keiner erinnert, bis zu dem Tag, an dem es darauf ankommt. Bau einen Server neu auf, und jeder Client schreit, dass sich der Host-Schlüssel geändert hat, also lernen die Leute, auch diese Warnung zu löschen.

Eine SSH-Zertifizierungsstelle beendet beides. Die CA signiert den Schlüssel jedes Hosts, und Clients vertrauen der CA, nicht einer Liste von Fingerabdrücken. Die CA signiert den Schlüssel jedes Benutzers für ein paar Stunden, und Server vertrauen der CA, nicht einer Liste von Schlüsseln. Nichts beim ersten Verbinden zu akzeptieren, nichts aufzuräumen, wenn jemand geht, und ein Benutzerzertifikat, das bis morgen von selbst stirbt.

Das ist ein anderer Aufbau als die X.509-Seite von step-ca aus Deine eigene Zertifizierungsstelle: step-ca im Container, deshalb hat er einen eigenen Beitrag. Derselbe Container, andere Schlüssel, andere Dateien auf jeder Maschine. Alles hier lief mit step-ca 0.30.2 und OpenSSH 10.0 in einem Podman-Pod.

Die SSH-CA einschalten

Die SSH-Schlüssel entstehen bei der ersten Einrichtung von step-ca oder gar nicht. Setz DOCKER_STEPCA_INIT_SSH=true beim ersten Start¹, und das Log zeigt zwei zusätzliche Schlüssel:

SSH Host CA Key: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy...
SSH User CA Key: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy...

Sie fügt außerdem einen sshpop-Provisioner hinzu, mit dem ein Host später sein eigenes Zertifikat erneuern kann. Läuft die CA schon ohne SSH, gibt es keinen Schalter zum Umlegen. Es ist eine neue CA.

Den Host signieren

Nimm den vorhandenen Host-Schlüssel des Servers, signiere ihn und gib das Zertifikat an den Server zurück:

step ssh certificate --host --sign \
  --provisioner admin --provisioner-password-file prov-pass \
  nas.home.example ssh_host_ecdsa_key.pub

Die Reihenfolge zählt. Mit den Provisioner-Flags hinter Hostname und Schlüsseldatei hat step abgelehnt:

too many positional arguments were provided in 'step ssh certificate <key-id> <key-file>'

Stell alle Flags nach vorn, und es signiert. Das Zertifikat, wie ssh-keygen -L es liest:

Der Principal ist der Name, den ein Client zum Verbinden benutzen muss. Verbinde dich über einen Namen, der nicht im Zertifikat steht, und der Client akzeptiert es nicht, also signiere jeden Namen, auf den der Host hört.

Der Server

Zwei Zeilen in sshd_config²:

HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
TrustedUserCAKeys /etc/ssh/ssh_user_ca_key.pub

HostCertificate gibt Clients das Host-Zertifikat, und sein Schlüssel „must match a private host key already specified“². TrustedUserCAKeys ist der öffentliche Schlüssel der Benutzer-CA, „trusted to sign user certificates for authentication“². Führ vor dem Neustart sshd -t aus. Ein Tippfehler in einem der Pfade, und sshd meldet Could not load host certificate, und das findest du weit lieber jetzt als in einer ausgesperrten Sitzung.

Auf dem Testserver gibt es überhaupt keine authorized_keys. ls /home/damien/.ssh/authorized_keys liefert No such file or directory, und die Anmeldungen unten funktionieren trotzdem.

Der Benutzer

Die CA erzeugt das Schlüsselpaar und signiert es in einem Rutsch:

step ssh certificate damien id_ecdsa \
  --provisioner admin --provisioner-password-file prov-pass

Sechzehn Stunden sind der Sinn der Sache. Sie decken einen Arbeitstag ab und sterben über Nacht. Einen Benutzer zu widerrufen heißt meistens, morgen nicht für ihn zu signieren.

Der Client

Eine Zeile in known_hosts ersetzt jeden Fingerabdruck, den sie sonst sammeln würde³:

@cert-authority *.home.example ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAy...

Das heißt: jeder Host unter home.example, dessen Zertifikat mit diesem Schlüssel signiert ist, ist echt. Die Markierung @cert-authority macht daraus eine CA-Zeile statt des Schlüssels eines einzelnen Hosts.

Was der Test gezeigt hat

Alle vier von einem Client aus, der nichts hatte außer dem Benutzerzertifikat und dieser einen known_hosts-Zeile, mit StrictHostKeyChecking=yes, damit nichts im Vorbeigehen akzeptiert werden konnte:

Der dritte ist der, den die Leute übersehen. Ein Zertifikat öffnet nicht jedes Konto auf der Kiste, nur die Principals, die darin stehen. Ein Schlüssel in jemandes authorized_keys kann das nicht.

Erneuern

Ein Host erneuert sein eigenes Zertifikat mit dem Schlüssel, den er schon hat. Das ist der sshpop-Provisioner, der „allows a client to renew, revoke, or rekey an SSH certificate using that certificate for authentication with the CA“⁴. Kein Passwort⁵:

step ssh renew --force ssh_host_ecdsa_key-cert.pub ssh_host_ecdsa_key

Eine neue Seriennummer und frische 30 Tage. Häng es an einen wöchentlichen Timer, und der Host läuft nie ab. Lade sshd danach neu, sonst bleibt das alte Zertifikat im Speicher.

Benutzer erneuern, indem sie noch einmal fragen. Ein step ssh certificate am Tag, oder bei der ersten Anmeldung des Tages, und das ist die ganze Arbeit.

Wo es an seine Grenzen kommt

Der letzte ist der Tausch. Jede authorized_keys-Datei war ihr eigenes kleines Risiko. Jetzt gibt es ein großes, an einem Ort. Das ist besser, weil sich ein Ort überwachen und absichern lässt, aber nur, wenn es jemand tut.

Vertrauen dort, wo es sich prüfen lässt

Die Fingerabdruck-Abfrage und die authorized_keys-Datei haben etwas gemeinsam. Beide verlangen von einem Menschen eine Vertrauensentscheidung ohne Informationen, jeden Tag, für immer. Darin sind Menschen nicht gut und werden es nie sein, also hören sie auf zu entscheiden und fangen an, yes zu tippen.

Eine CA verlegt diese Entscheidung an einen Ort, einmal, wo sie ordentlich getroffen werden kann. Das ist die ganze Idee, und es ist dieselbe hinter jedem Standard, der etwas taugt: das Sorgfältige einmal tun, es aufschreiben und aufhören, von Leuten zu verlangen, es hundertmal die Woche im Kopf zu erledigen. Die Maschine prüft die Signatur. Du prüfst die CA. Das ist eine Arbeitsteilung, die hält.