Je ne veux pas simplement mettre la clé RSA publique d'un certificat x.509 dans ~/.ssh/authorized_keys
- Je cherche un moyen de configurer un ssh de telle sorte que les certificats x.509 signés par une autorité de certification prédéfinie se voient automatiquement accorder l'accès au compte d'utilisateur lié. RFC 6187 semble suggérer une telle fonctionnalité, mais je ne trouve aucune documentation à ce sujet, ni si elle est implémentée dans OpenSSH.
Voici une description plus élaborée de ce que je veux faire:
keyUsage=digitalSignature
(et peut-être le id-kp-secureShellClient
champ extendedKeyUsage)authorized_keys
. Au lieu de cela, il est configuré pour faire confiance à SSH-CA pour vérifier la clé publique et la signature du certificat (ou de la chaîne de certificats) et le nom d'utilisateur/UID (probablement directement dans le champ subjectAltName
, ou peut-être en utilisant un serveur -side mapping) avant que l'authentification RSA habituelle n'ait lieuDonc, (comment) cela peut-il être réalisé avec OpenSSH, et si cela nécessite un correctif, comment les modifications côté client peuvent-elles être minimisées?
Comme alternative, je suppose que l'on pourrait également utiliser n'importe quel certificat S/MIME plus un mappage de nom d'utilisateur à adresse e-mail, sans avoir besoin d'une propre autorité de certification. Le client peut également utiliser uniquement la clé RSA privée et un serveur de certificats est utilisé pour obtenir un certificat à partir d'une clé publique, offrant également la possibilité d'utiliser des certificats PGP (par exemple via monkeysphere ) sans l'utilisateur nécessitant une connaissance de tout cela tant qu'ils fournissent simplement une clé publique.
Si ce n'est pas possible nativement, je suppose que je pourrais proposer une "implémentation" semi-automatique de ceci en laissant un script sur le serveur vérifier automatiquement un certificat soumis d'une autre manière via openssl
(ou gnupg
) et que la clé publique soit affectée à l'utilisateur respectif authorized_keys
fichier - bien qu'à ce point je suis probablement plus ou moins refaire le projet monkeyshere ...
OpenSSH ne prend pas officiellement en charge l'authentification basée sur un certificat x.509:
Les développeurs ont maintenu une position selon laquelle la complexité des certificats X.509 introduit une surface d'attaque inacceptable pour sshd. Au lieu de cela, ils ont [récemment] mis en œuvre un format de certificat alternatif qui est beaucoup plus simple à analyser et présente donc moins de risques.
...
OpenSSH utilise simplement les algorithmes cryptographiques de bas niveau d'OpenSSL.
Cependant Roumen Petrov publie des versions d'OpenSSH qui incluent le support X.509 , et vous pouvez essayer avec celles-ci.
Les certificats X.509 peuvent [être] utilisés comme "identité d'utilisateur" et/ou "clé d'hôte" dans les authentifications SSH "Clé publique" et "Basé sur l'hôte".
Les versions de Roumen Petrov peuvent être téléchargées via cette page .
Voici un guide Debian pour SSH avec clé d'authentification au lieu de mot de passe qui pourrait également s'avérer utile dans la configuration de votre OpenSSH pour accepter la PKI x509 pour l'authentification des utilisateurs.
L'authentification native basée sur les certificats est disponible dans OpenSSH en amont non modifié. Il n'est cependant pas basé sur x.509.
Générez d'abord votre CA:
ssh-keygen -f ssh-ca
Ensuite, installez votre clé CA dans .authorized_keys
avec un cert-authority
préfixe:
echo "cert-authority $(<ssh-ca.pub)" >>.ssh/authorized_keys
À partir de là, chaque fois qu'une clé est générée par un utilisateur:
ssh-keygen -f real-key
... la partie publique peut être signée par votre autorité de certification SSH, après quoi elle sera approuvée par le serveur sans que cette clé elle-même soit ajoutée à authorized_keys
:
ssh-keygen -s ssh-ca -I identifier_for_your_real_key_goes_here real-key.pub
Avec OpenSSH, ce n'est pas possible. Comme l'a dit @TildalWave, vous devez utiliser la fourche de Roumen Petrov PKIXSSH .
Une fois que vous avez votre certificat X509 vous n'avez pas besoin d'ajouter la clé publique sur le authorized_keys
fichier.
Vous devez configurer deux choses du côté serveur :
Ajoutez le certificat de l'autorité de certification dans le répertoire défini par la directive CACertificatePath
dans sshd_config
fichier (normalement /etc/ssh/ca/crt
, Je pense) avec un lien pour le hachage du certificat.
Pour créer le lien, utilisez openssl. Supposons que le certificat CA a été copié sous /ect/ssh/ca/crt/ca.crt
les commandes seront:
cd /etc/ssh/ca/crt/
ln -s ca.crt `openssl x509 -in ca.crt -noout -hash`.0
Ajoutez les informations "sujet" du certificat x509 au authorized_keys
fichier de l'utilisateur (dans le serveur de destination)
Supposons que la clé privée et le certificat X509 de l'utilisateur se trouvent dans ssh/id_rsa
pour exécuter le sujet dans le client:
openssl x509 -noout -subject -in .ssh/id_rsa
Et eux sur le serveur, ajoutez cette ligne avec le préfixe x509v3-sign-rsa subject=
à la authorized_keys
.
Cette ligne aura un contenu similaire à celui-ci:
x509v3-sign-rsa subject= /C=ES/ST=Pontevedra/L=Vigo/CN=testssh/[email protected]
Comme nous pouvons le voir, l'authentification est réellement effectuée en faisant confiance à l'autorité de certification pour tout certificat x509 valide de l'utilisateur . Nous pourrions générer un nouveau certificat et il sera accepté sans aucune intervention côté serveur.
Après avoir lutté pendant quelques jours, j'ai écrit un article expliquant le processus complet sur un blog que je viens de déployer. Vous pouvez le lire sur "OpenSSH avec les certificats X509 COMMENT FAIRE" .
Clés SSH signées CA
Lorsque vous souhaitez gérer l'accès des utilisateurs en dehors des limites, vous ne voulez pas installer leur clé publique dans les fichiers authorized_keys sur les serveurs auxquels ils doivent accéder. Vous ne souhaitez pas non plus gérer les comptes personnels, mais plutôt utiliser un principal (compte fonctionnel, c'est-à-dire administrateur) et lui accorder un bail.
Vous pouvez créer une autorité de signature de certificat pour Secure Shell (différente de X509 TLS/SSL) simplement en créant une paire de clés ssh. La clé publique de l'autorité de certification est installée sur tous les serveurs, et c'est le seul fichier qui doit s'y trouver. (Vous pouvez avoir 2 clés CA dans le fichier ou plus si vous en avez besoin.)
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/ca_ssh
cat ~/.ssh/ca_ssh.pub
Copiez ce fichier sur les serveurs et ajoutez-le à /etc/ssh/sshd_config
:
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
Accorder l'accès
Pour signer la clé publique de Fred (fred.pub) afin d'accorder une semaine d'accès au serveur en tant qu'administrateur et de vous connecter en tant que personnel dans/var/log/secure, exécutez cette commande et renvoyez le fichier fred.pub-cert à Fred.
ssh-keygen -s ~/.ssh/ca_ssh -I staff -n admin -V +1w fred.pub
Révocation des clés
Ajoutez les clés publiques des personnes qui ne devraient plus se connecter pendant leur bail à playbook_dir/files/ssh/revoked_keys