Si vous interagissez régulièrement avec des commandes SSH et des hôtes distants, vous trouverez peut-être pratique d'utiliser une paire de clés au lieu de mots de passe. Au lieu que le système distant demande un mot de passe à chaque connexion, l'authentification peut être automatiquement négociée à l'aide d'une paire de clés publique et privée.
La clé privée reste sécurisée sur votre propre poste de travail et la clé publique est placée à un emplacement spécifique sur chaque système distant auquel vous accédez. Votre clé privée peut être sécurisée localement avec une phrase de passe. Un programme de mise en cache local tel que ssh-agent ou gnome-keyring vous permet de saisir cette phrase de passe périodiquement, au lieu de chaque fois que vous utilisez la clé pour accéder à un système distant.
[ Téléchargement gratuit :Aide-mémoire sur les commandes Linux avancées. ]
Génération d'une paire de clés et propagation de la clé publique
Générer votre paire de clés et propager votre clé publique est plus simple qu'il n'y paraît. Parcourons-le.
Génération de la clé
L'effort minimum pour générer une paire de clés consiste à exécuter le ssh-keygen commande, et en choisissant les valeurs par défaut à toutes les invites :
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/training/.ssh/id_rsa):
Created directory '/home/training/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/training/.ssh/id_rsa.
Your public key has been saved in /home/training/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:qOoqJFfbfnBFMZ6WFsZQZfy6WXTfcknQEd0B+quTjHw [email protected]
The key's randomart image is:
+---[RSA 2048]----+
| .+*+o.o+*|
| oo*o. .o|
| .*. .. |
| . . o. . o..|
| . o. S. +..+|
|... ..o . . +.+|
|o. .. o. o .= o |
|. . . .o E+ |
|ooo . ... |
+----[SHA256]-----+
L'emplacement par défaut pour stocker les clés est dans le ~/.ssh répertoire, qui sera créé s'il n'existe pas :
$ ls -al .ssh
total 16
drwx------. 2 training training 4096 Aug 12 07:43 .
drwx------. 5 training training 4096 Aug 12 07:43 ..
-rw-------. 1 training training 1843 Aug 12 07:43 id_rsa
-rw-r--r--. 1 training training 415 Aug 12 07:43 id_rsa.pub
Autoriser cette commande à créer le répertoire garantit également que le propriétaire et les autorisations sont correctement définis. Certaines applications n'utiliseront pas de clés si les autorisations sur la clé privée sont trop ouvertes.
Le fichier se terminant par .pub est la clé publique qui doit être transférée aux systèmes distants. C'est un fichier contenant sur une seule ligne :Le protocole, la clé, et un email servant d'identifiant. Options pour le ssh-keygen permet de spécifier un identifiant différent :
$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZ4SCcMX1EK31G/qLyCs3PaFcWkx0QA61OwQNHYztvrg7iD/etN4S5UP6ugHjTcUvqD/fZJFBJeryK0Hz0FzejKYiJBxQuUqadyXFSW30VnW6mAzgNoz20rGc2mipUrsaqdBWWv5U7vX8sgjEHEgVHzq6pfWj681PtikJ8Dss1IvPiPvOoRz2jb1dQnnrAVqMDGeWbm4yjYQamPvnLo1Hy23NgXpZ7KXv9PuDDu3tqcoMUqFk7sHswMrCCUY9SWOD5JBbhD3JX4LPs68WWbETOqOQ3a9ebTsL3wRPSbuu/djhL9Qmd8fN2OaM2U2zFpeE3NzBq4KT/ml6RTv44EMuh [email protected]
Après avoir généré la paire de clés, le ssh-keygen La commande affiche également l'empreinte digitale et l'image aléatoire uniques à cette clé. Ces informations peuvent être partagées avec d'autres personnes qui pourraient avoir besoin de vérifier votre clé publique.
Plus tard, vous pourrez les visualiser avec :
$ ssh-keygen -lv
Enter file in which the key is (/home/training/.ssh/id_rsa):
Le -l L'option répertorie l'empreinte digitale et le -v l'option ajoute l'art ASCII.
Propagation de la clé publique à un système distant
Si l'authentification par mot de passe est actuellement activée, le moyen le plus simple de transférer la clé publique vers l'hôte distant consiste à utiliser le ssh-copy-id commande. Si vous avez utilisé le nom par défaut pour la clé, il vous suffit de spécifier l'utilisateur distant et l'hôte :
$ ssh-copy-id susan@streamer
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/training/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
susan@streamer's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'susan@streamer'"
and check to make sure that only the key(s) you wanted were added.
En suivant les instructions de la sortie, vérifiez que vous pouvez vous connecter à l'aide de la paire de clés. Si vous avez implémenté une phrase secrète, vous serez invité à saisir la phrase secrète pour utiliser la clé privée :
$ ssh susan@streamer
Last login: Sat Aug 10 14:09:33 2019 from X.X.X.X
Examinez le fichier de clé autorisé résultant. C'est là que la clé publique a été ajoutée. Si le répertoire ou le fichier n'existait pas, alors il a été (ou ils ont été) créé avec la propriété et les autorisations correctes. Chaque ligne est une seule clé publique autorisée :
[susan@streamer ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZ4SCcMX1EK31G/qLyCs3PaFcWkx0QA61OwQNHYztvrg7iD/etN4S5UP6ugHjTcUvqD/fZJFBJeryK0Hz0FzejKYiJBxQuUqadyXFSW30VnW6mAzgNoz20rGc2mipUrsaqdBWWv5U7vX8sgjEHEgVHzq6pfWj681PtikJ8Dss1IvPiPvOoRz2jb1dQnnrAVqMDGeWbm4yjYQamPvnLo1Hy23NgXpZ7KXv9PuDDu3tqcoMUqFk7sHswMrCCUY9SWOD5JBbhD3JX4LPs68WWbETOqOQ3a9ebTsL3wRPSbuu/djhL9Qmd8fN2OaM2U2zFpeE3NzBq4KT/ml6RTv44EMuh [email protected]
Pour révoquer l'accès à cette paire de clés, supprimez la ligne de la clé publique.
De nombreuses autres options peuvent être ajoutées à cette ligne dans le fichier de clé autorisée pour contrôler l'accès. Ces options sont généralement utilisées par les administrateurs plaçant les clés publiques sur un système avec des restrictions. Ces restrictions peuvent inclure l'origine de la connexion, la ou les commandes pouvant être exécutées et même une date indiquant quand arrêter d'accepter cette clé. Ces options et bien d'autres sont listées dans le sshd page de manuel.
Modification de la phrase secrète
Si vous devez modifier une phrase de passe sur votre clé privée ou si vous avez initialement défini une phrase de passe vide et souhaitez cette protection ultérieurement, utilisez le ssh-keygen commande avec le -p choix :
$ ssh-keygen -p
Enter file in which the key is (/home/training/.ssh/id_rsa):
Key has comment '[email protected]'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
Vous pouvez ajouter des options supplémentaires pour spécifier la clé (-f ) et l'ancien (-P ) ou nouveau (-N ) phrases secrètes sur la ligne de commande. N'oubliez pas que tous les mots de passe spécifiés sur la ligne de commande seront enregistrés dans l'historique de votre shell.
Voir le ssh-keygen page de manuel pour des options supplémentaires.
Rotation des touches
Bien que la clé publique en elle-même soit destinée à être partagée, gardez à l'esprit que si quelqu'un obtient votre clé privée, il peut ensuite l'utiliser pour accéder à tous les systèmes qui possèdent la clé publique. Ces paires de clés n'ont pas non plus de période de validité comme les clés GNU Privacy Guard (GPG) ou les certificats d'infrastructure à clé publique (PKI).
Si vous avez des raisons de soupçonner qu'une clé privée a été volée ou autrement compromise, vous devez remplacer cette paire de clés. L'ancienne clé publique doit être supprimée de tous les systèmes, une nouvelle clé doit être générée avec ssh-keygen , et la nouvelle clé publique doit être transférée vers les systèmes distants souhaités.
Si vous effectuez une rotation de clés par précaution et sans aucun souci de compromission, vous pouvez utiliser l'ancienne paire de clés pour authentifier le transfert de la nouvelle clé publique avant de retirer l'ancienne clé.
L'utilisation de phrases secrètes vides est-elle déjà une bonne idée ?
Il y a plusieurs éléments à prendre en compte lorsque vous envisagez une phrase de passe vide pour votre clé privée SSH.
Dans quelle mesure le fichier de clé privée est-il sécurisé ?
Si vous avez tendance à travailler à partir de plusieurs systèmes clients et que vous souhaitez disposer de plusieurs copies de votre clé ou en conserver une copie sur un support amovible, il est vraiment judicieux d'avoir une phrase de passe sur la clé privée. Cette pratique s'ajoute à la protection de l'accès au fichier clé avec un support chiffré.
Cependant, si vous n'avez qu'une seule copie de la clé privée et qu'elle est conservée sur un système bien sécurisé et non partagé, alors avoir une phrase de passe est simplement un niveau de protection supplémentaire au cas où.
N'oubliez pas que la modification de la phrase secrète sur une copie ne modifie pas la phrase secrète sur les autres copies. La phrase de passe verrouille simplement l'accès à un fichier clé spécifique.
Pourquoi pensez-vous avoir besoin d'une phrase secrète vide ?
Il existe des cas pour les clés avec des mots de passe vides. Certains utilitaires qui doivent transférer automatiquement des fichiers entre systèmes nécessitent une méthode sans mot de passe pour s'authentifier. Le kdump utilitaire, lorsqu'il est configuré pour vider le noyau sur un système distant à l'aide de SSH, en est un exemple.
Une autre utilisation courante consiste à générer une paire de clés pour un script conçu pour s'exécuter sans surveillance, par exemple à partir d'une tâche cron.
Que diriez-vous d'une alternative intermédiaire ?
En soi, une clé privée protégée par une phrase de passe nécessite que la phrase de passe soit saisie chaque fois que la clé est utilisée. Cette configuration ne ressemble pas à SSH sans mot de passe. Cependant, il existe des mécanismes de mise en cache qui vous permettent d'entrer la phrase secrète de la clé une seule fois, puis d'utiliser la clé encore et encore sans ressaisir cette phrase secrète.
OpenSSH est livré avec un ssh-agent démon et un ssh-add utilitaire pour mettre en cache la clé privée déverrouillée. Le bureau GNOME dispose également d'un démon de trousseau de clés qui stocke les mots de passe et les secrets, mais implémente également un agent SSH.
La durée de vie de la clé en cache peut être configurée avec chacun des agents ou lorsque la clé est ajoutée. Dans de nombreux cas, sa durée de vie est par défaut illimitée, mais le cache est effacé lorsque l'utilisateur se déconnecte du système. Vous serez invité à saisir la phrase secrète une seule fois par session de connexion.
Si une application planifiée doit s'exécuter en dehors d'une session de connexion utilisateur, il peut être possible d'utiliser un secret ou un autre gestionnaire de mots de passe pour automatiser le déverrouillage de la clé. Par exemple, Ansible Tower stocke les informations d'identification dans une base de données sécurisée. Cette base de données comprend une clé privée SSH utilisée pour se connecter aux systèmes distants (nœuds gérés) et toutes les phrases secrètes nécessaires pour ces clés privées. Une fois ces informations d'identification stockées, une tâche peut être planifiée pour exécuter un playbook selon un calendrier régulier.
Automatisation de la propagation
Un gestionnaire d'identité centralisé tel que FreeIPA peut aider à la propagation des clés. Téléchargez la clé publique sur le serveur en tant qu'attribut d'un compte d'utilisateur, puis propagez-la aux hôtes du domaine si nécessaire. FreeIPA peut également fournir un contrôle d'accès supplémentaire basé sur l'hôte pour savoir où une clé peut être utilisée.
Les clés peuvent également être distribuées à l'aide de modules Ansible. Le openssh_keypair le module utilise ssh-keygen pour générer des clés et la authorized_key module ajoute et supprime les clés autorisées SSH pour des comptes d'utilisateurs particuliers.
Conclusion
Les paires de clés SSH ne sont qu'un moyen d'automatiser l'authentification sans mot de passe. L'utilisation de l'authentification GSSAPI (Generic Security Services Application Program Interface) est également courante lorsque l'on tente de réduire l'utilisation de mots de passe sur un réseau avec une gestion centralisée des utilisateurs. Les paires de clés SSH sont l'option la plus simple à mettre en œuvre lorsque l'authentification unique (SSO) n'est pas déjà disponible.
De nombreux référentiels de code source autorisent l'accès à l'aide de clés SSH. Vous pouvez télécharger une clé publique sur un compte de l'organisation d'hébergement, comme les sites Fedora Account System, GitLab ou GitHub, et utiliser cette paire de clés pour vous authentifier lors de l'extraction et de la transmission de contenu vers des référentiels.