Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
howtos:sshexpert [2017/11/27 20:00] – angelegt morquai | howtos:sshexpert [2017/12/02 16:09] – [Signieren eines Hostkeys] morquai | ||
---|---|---|---|
Zeile 6: | Zeile 6: | ||
Genauso, wie der Server ein Interesse daran hat, die User zu authentifizieren, | Genauso, wie der Server ein Interesse daran hat, die User zu authentifizieren, | ||
Nun aber in Media Res: | Nun aber in Media Res: | ||
- | ===== Certification Authority anlegen ===== | + | ===== Certification Authority |
+ | 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, | ||
+ | Der Key wird wie immer mit ssh-keygen angelegt | ||
+ | ssh-keygen -b 2048 -t rsa -C "Meine Certification Authority" | ||
+ | Dieser Key wird nun genutzt, um die Public Keys der User zu signieren. | ||
+ | ===== SSH Key eines Users signieren ===== | ||
+ | ssh-keygen -s id_rsa_userca -I " | ||
+ | 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: | ||
+ | Signing CA: RSA SHA256: | ||
+ | Key ID: " | ||
+ | Serial: 1 | ||
+ | Valid: from 2017-11-27T21: | ||
+ | Principals: | ||
+ | unixuser1 | ||
+ | unixuser2 | ||
+ | Critical Options: (none) | ||
+ | Extensions: | ||
+ | permit-X11-forwarding | ||
+ | permit-agent-forwarding | ||
+ | permit-port-forwarding | ||
+ | permit-pty | ||
+ | permit-user-rc | ||
+ | ===== SSH Server konfigurieren ===== | ||
+ | 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 / | ||
+ | TrustedUserCAKeys / | ||
+ | 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 " | ||
+ | Will man nun sicherstellen, | ||
+ | PubkeyAcceptedKeyTypes | ||
+ | | ||
+ | | ||
+ | the specified value begins with a ‘+’ character, then the | ||
+ | | ||
+ | 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, | ||
+ | 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 (~/ | ||
+ | cert-authority ssh-rsa AAAAB3NzaC1yc2EAAA..../ | ||
+ | ===== Jetzt das Ganze für den Server ===== | ||
+ | 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 ~/ | ||
+ | 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.\\ | ||
+ | ==== Signieren eines Hostkeys ==== | ||
+ | Man kann natürlich denselben CA Keys benutzen wie für die Benutzerauthentifizierung, | ||
+ | ssh-keygen -b 2048 -t rsa -C "Meine Certification Authority" | ||
+ | Das signieren der Host Keys funktioniert (fast) genauso wie bei User Keys: | ||
+ | ssh-keygen -s id_rsa_hostca -I " | ||
+ | Jeder in der / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | Der Benutzer muss nun in seiner ~/ | ||
+ | echo ' | ||
+ | ===== Das war es auch schon ===== | ||
+ | Mit einer solchen Konfiguration kann nun der Server sicherstellen, | ||
+ | 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. | ||
+ | | ||
+ | |||
+ | |||
+ | | ||
+ | | ||