Die Authentifizierung über OpenSSH Keys haben wir schon angesprochen. Das Ganze hat aber ein paar Unschönheiten. Zum einen muss der Public Key erstmal in die authorized_keys Datei des Servers gelangen (siehe ssh-copy-id), wozu erstmal ein Passwort erforderlich ist. Passworte haben aber die unangenehme Eigenschaft abzulaufen und daher regelmäßig geändert werden müssen, auch wenn man sie gar nicht benutzt.
Will man die Berechtigung zentral verwalten meist die Passwort Authentifizierung im SSH abgeschaltet um sicherzustellen, das die Server nur von ausgewähltem Personal erreicht werden können. Darüberhinaus kommen auch SSH private Keys, genau wie Passworte, schon mal abhanden, sind also „verbrannt“. Aus Sicherheitsgründen sollten also auch die Key Pairs regelmässig ausgewechselt werden. Also muss auch das Alter eines Keys nachgehalten werden.
All diese Dinge können ad acta gelegt werden, wenn man die Keys authorisiert und diese Authorisierung im Key hinterlegt. Wenn man nun der authorisierenden Stelle (oder Person) vertraut, reicht es aus, wenn ein SSH Key unterschrieben (digita signiert) ist.

Genauso, wie der Server ein Interesse daran hat, die User zu authentifizieren, benötigt auch der Benutzer eine Möglichkeit den Server als vertrauenswürdig zu erkennen. OpenSSH bietet nicht nur die Möglichkeit, den Key des Benutzers zu signieren sondern auch den des Servers. Auch die OpenSSH Hostkeys können also signiert werden und der User kann die Signatur des Hostkeys prüfen.
Nun aber in Media Res:

Die CA besteht eigentlich nur aus einem Key Pair, wie jeder andere SSH-Key. Allerdings wird dieser Key nicht zur Authentifizierung eines Benutzers sondern zur Erstellung einer digitalen Signatur genutzt. Idealerweise liegt der private Key der CA auf einem Rechner ohne Internetverbundung, um zu vermeiden das Hacker selbst ihre Keys signieren.
Der Key wird wie immer mit ssh-keygen angelegt

ssh-keygen -b 2048 -t rsa -C "Meine Certification Authority" -N "Passphrase" -f id_rsa_userca

Dieser Key wird nun genutzt, um die Public Keys der User zu signieren.

ssh-keygen -s id_rsa_userca -I "vorname.machname@example.com" -n "unixuser1,unixuser2" -V +2w -z 1 id_rsa.pub

Damit ist der Key signiert, und man kann die Signatur mit ssh-keygen anschauen:

ssh-keygen.exe -L -f id_rsa-cert.pub  

Die Ausgabe sieht wie folgt aus:

id_rsa-cert.pub:
      Type: ssh-rsa-cert-v01@openssh.com user certificate
      Public key: RSA-CERT SHA256:gbg5aGoDtSFwl5sz9kf19IxbrooD6BrpaqQubSA2MLU
      Signing CA: RSA SHA256:RgdqfmX3VxV+Gd5dYQdOPlywoVSbxif0tSyoQASq8gg
      Key ID: "vorname.machname@example.com"
      Serial: 1
      Valid: from 2017-11-27T21:12:00 to 2017-12-11T21:13:50
      Principals:
              unixuser1
              unixuser2
      Critical Options: (none)
      Extensions:
              permit-X11-forwarding
              permit-agent-forwarding
              permit-port-forwarding
              permit-pty
              permit-user-rc

Der Unterschied zwischen einem klassischen SSH Key und einem mit Signatur liegt darin wem man vertraut, dem Key oder demjenigen der ihn signiert hat. Bisher musste man jeden Key dem man vertraut bei jedem User auf jedem Server hinterlegen. Durch das Vertrauen in die Signatur reicht es aus, dem SSH Server die Keys, deren Signatur man vertraut, einmal bekannt zu machen.
Um dies zu tun muss man den oben generierten Public Key der CA nach /etc/ssh kopieren und folgende Zeile in die /etc/ssh/sshd_config eingetragen werden:

TrustedUserCAKeys /etc/ssh/id_rsa_userca.pub

Die Datei die hinter TrustedUserCAKeys angegeben wird kann, wie eine authorized_keys Datei, auch mehrere Keys beinhalten, es kann also bei Bedarf auch mehrere Stellen geben, deren Signatur man vertraut.
Wenn man auf diese Weise vorgeht, muss der signierte SSH Public Key innerhalb der Signatur eine Information enthalten, für welchen Unix User die Signatur verwendet werden darf. Im SSH Jargon nennt man dies die „Principals“. Im Beispiel oben steht diese Angabe hinter dem „-n“ Flag, das Zertifikat ist also für die Benutzer „unixuser1“ und „unixuser2“ gültig. Darüberhinaus kann, wie gewohnt, ein signierter Key auch in der authorized Keys Datei benutzt werden. Im letzteren Fall wird dann wieder dem Key und nicht der Signatur vertraut.
Will man nun sicherstellen, das nur signierte Keys zum Einsatz kommen, kann man dies in der /etc/sshd_config festlegen. Hier ein Auszug aus der man-page zu sshd_config:

PubkeyAcceptedKeyTypes
           Specifies the key types that will be accepted for public key
           authentication as a comma-separated pattern list.  Alternately if
           the specified value begins with a ‘+’ character, then the
           specified key types will be appended to the default set instead
           of replacing them.  The default for this option is:
              ecdsa-sha2-nistp256-cert-v01@openssh.com,
              ecdsa-sha2-nistp384-cert-v01@openssh.com,
              ecdsa-sha2-nistp521-cert-v01@openssh.com,
              ssh-ed25519-cert-v01@openssh.com,
              ssh-rsa-cert-v01@openssh.com,
              ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa

Lässt man die letzte Zeile weg (und natürlich das Komma davor), wird der SSH Server alle nicht signierten Zertifikate ignorieren.
Natürlich besteht auch die Möglichkeit die vertrauenswürdigen CA's bei jedem User zu definieren, was aber aus meiner Sicht nur in seltenen Ausnahmefällen sinnvoll ist. Die Vorgehensweise ist wie bei klassischen Key, die in der authorized_keys Datei (~/.ssh/authorized_keys) hinterlegt werden. Statt der einzelnen Public Keys wird bei signierten Keys nur die CA hinterlegt. Hier mal ein Beispiel eines solchen Eintrags

cert-authority ssh-rsa AAAAB3NzaC1yc2EAAA..../HwuqVctCokyhvtzOrpv0919UMDgpZTH Kommentar

Wir können jetzt über signierte SSH Keys auf dem Server den Benutzer identifizieren. Aber das ist ja nur die halbe Miete, denn so wir der Server den User identifizieren möchte, hat der User ein Interesse daran den Server eindeutig zu identifizieren. Normalerweise werden die Public Keys der bekannten Server in der ~/.ssh/known_hosts Datei hinterlegt. Bei der ersten Kontaktaufnahme wir der Fingerprint des Hosts angezeigt und der Benutzer gefragt ob er wirklich diesen Server meint. Bei positiver Antwort wird vom SSH Client automatisch ein entsprechender Eintrag in der known_hosts Datei gemacht.
Leider macht sich eigentlich niemand den ich kenne die Mühe der Fingerprint wirklich zu prüfen und nickt die Bestätigungsfrage einfach ab. Mit signierten SSH Host-Keys macht man sich das Leben einfacher, denn man vertraut ja der CA. Kommt nun eine Frage bzgl. eines unbekannten Host-Keys liegt die Vermutung nahe, das es sich nicht um den richtigen Server handelt.

Man kann natürlich denselben CA Keys benutzen wie für die Benutzerauthentifizierung, sinnvoller ist es aber einen eigenen CA-Key für Hosts anzulegen

ssh-keygen -b 2048 -t rsa -C "Meine Certification Authority" -N "Passphrase" -f id_rsa_hostca

Das signieren der Host Keys funktioniert (fast) genauso wie bei User Keys:

ssh-keygen -s id_rsa_hostca -I "serveradmin@example.com" -h -n server1.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Jeder in der /etc/ssh/sshd_config angegebene Key muss einzeln signiert werden, i.d.R. sind dies

/etc/ssh_host_dsa_key.pub
/etc/ssh_host_ecdsa_key.pub
/etc/ssh_host_ed25519_key.pub
/etc/ssh_host_rsa_key.pub

Der Benutzer muss nun in seiner ~/.ssh/known_hosts folgende Eintrag machen, um allen Hostkeys, die mit dem Key id_rsa_hostca signiert sind, zu vertrauen. Dazu benötigt er den Public Key der signierenden SSH Keys. Folgender Befehl fügt nun die entsprechende Zeile zur known_hosts Datei hinzu (am Ende)

echo '@cert-authority *.example.com ' $(cat id_rsa_hostca) >>~/.ssh/known_hosts

Mit einer solchen Konfiguration kann nun der Server sicherstellen, das die Benutzer vertrauenswürdig sind und andererseits der Benutzer sicher sein wirklich mit dem erwarteten Server verbunden zu sein.
Da Vertrauen zeitlich begrenzt sein kann besteht die Möglichkeit jeder Signatur einen Gültigkeitszeitraum zuzuordnen. Insbesondere kann sichergestellt werden, das bei Benutzern der SSH-Key, wie von Passworten gewohnt, regelmäßig neu erstellt wird. Derjenige, der die Signatur eines User Keys durchführt muss nur den alten und den neuen Public Key vergleichen. Ein gleicher Public Key bedeutet auch, das der gleich Private Key zum Einsatz kam.