Comment gérer plusieurs clés SSH

Il est sûr de dire que la plupart des développeurs de la sphère Web ont à un moment donné rencontré SSH. SSH est l'un des protocoles les plus utilisés pour l'échange de données en toute sécurité. Vous utilisez SSH pour vous connecter à des serveurs distants, ce qui inclut également la gestion de votre code à l'aide de Git et la synchronisation avec des référentiels distants.

Même s'il est considéré comme une bonne pratique d'avoir une paire de clés privée-publique par appareil, vous devez parfois utiliser plusieurs clés et / ou vous avez des noms de clés peu orthodoxes.

Vous utilisez peut-être une paire de clés SSH pour travailler sur les projets internes de votre entreprise, mais vous utilisez peut-être une clé différente pour accéder aux serveurs de certains clients d'entreprise. Vous pouvez même utiliser une clé différente pour accéder à votre propre serveur privé.

La gestion des clés SSH peut devenir fastidieuse dès que vous devez utiliser une deuxième clé. J'espère que cet article sera utile à quiconque rencontre des problèmes avec la gestion des clés SSH.

Je suppose que le lecteur a une connaissance de base de Git et SSH. La plupart des exemples tout au long de l'article utiliseront Git. Bien entendu, tout cela s'appliquera à toute autre communication SSH. Cela étant dit, certaines astuces spécifiques à Git sont incluses.

Attachez-vous, c'est parti!

Gérer une clé SSH

Tout d'abord, voyons à quoi pourrait ressembler votre flux de travail avant d'avoir à vous soucier de plusieurs clés.

Vous avez une clé privée stockée ~/.ssh/id_rsaavec une clé publique correspondante ~/.ssh/id_rsa.pub.

Imaginons que vous souhaitiez pousser / extraire des modifications de code vers / depuis un serveur Git distant - disons GitHub, pourquoi pas. Pour ce faire, vous devez d'abord ajouter votre clé publique à GitHub.

Je ne reviendrai pas sur cette étape, il devrait être assez facile de savoir comment procéder. J'ai également supposé que vous vous appelez Steve et que vous travaillez sur un projet top secret qui utilise Raspberry Pies pour détecter le trafic réseau.

Pour commencer votre travail, vous devez cloner un référentiel git en utilisant SSH:

git clone [email protected]:steve/raspberry-spy.git

À ce moment, GitHub ressemblera à: «Yo, c'est un dépôt privé! Nous devons chiffrer le trafic à l'aide de cette clé publique que j'ai ici et de votre clé privée. "

Vous avez ajouté la clé publique à votre profil sur GitHub, mais SSH doit en quelque sorte déterminer où se trouve votre clé privée correspondante.

Comme nous n'avons aucune idée de la clé privée à utiliser lors de la connexion [email protected]SSH, le client SSH essaie de trouver une clé à l'emplacement par défaut, ce qui est ~/.ssh/id_rsa- c'est sa meilleure estimation. S'il n'y a pas de fichier à cet emplacement, vous obtiendrez une erreur:

Cloning into 'raspberry-spy'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Si vous avez une clé privée stockée dans un fichier ~/.ssh/id_rsa, le client SSH utilisera cette clé privée pour le cryptage des communications. Si cette clé est mot de passe (comme il se doit), vous serez invité à entrer un mot de passe, comme ceci:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

Si vous entrez la bonne phrase de passe et si cette clé privée est bien celle qui correspond à la clé publique que vous avez attachée à votre profil, tout ira bien et le référentiel sera cloné avec succès.

Mais que faire si vous avez nommé votre clé différemment (ex. ~/.ssh/_id_rsa)? Le client SSH ne pourra pas déterminer où la clé privée est stockée. Vous obtiendrez la même Permission denied ...erreur qu'avant.

Si vous souhaitez utiliser une clé privée que vous avez nommée différemment, vous devez l'ajouter manuellement:

ssh-add ~/.ssh/_id_rsa

Après avoir entré la phrase de passe, vous pouvez vérifier si la clé a été ajoutée à ssh-agent(client SSH) en exécutant ssh-add -l. Cette commande répertorie toutes les clés actuellement disponibles pour le client SSH.

Si vous essayez de cloner le référentiel maintenant, cela réussira.

Jusqu'ici tout va bien?

Si vous êtes attentif, vous pourriez commencer à remarquer des problèmes potentiels.

Premièrement, si vous redémarrez votre ordinateur, ssh-agentil redémarrera et vous devrez ajouter vos clés non nommées par défaut en utilisant ssh-addà nouveau, en tapant des mots de passe et tout ce qui est fastidieux.

Pouvons-nous automatiser l'ajout de clés ou spécifier d'une manière ou d'une autre la clé à utiliser lors de l'accès à certains serveurs?

Pouvons-nous en quelque sorte enregistrer les mots de passe pour ne pas avoir à les saisir à chaque fois? Si seulement il y avait quelque chose comme un trousseau pour enregistrer les clés SSH protégées par mot de passe?.

Rassurez-vous, il y a des réponses à toutes ces questions.

Entrez, SSH config

En fait, le fichier de configuration SSH est une chose, une chose qui peut nous aider. Il s'agit d'un fichier de configuration par utilisateur pour la communication SSH. Créez un nouveau fichier: ~/.ssh/configet ouvrez-le pour le modifier.

Gestion des clés SSH nommées personnalisées

La première chose que nous allons résoudre en utilisant ce configfichier est d'éviter d'avoir à ajouter des clés SSH personnalisées à l'aide de ssh-add. En supposant que votre clé SSH est nommée ~/.ssh/_id_rsa, ajoutez ce qui suit au configfichier:

Host github.com HostName github.com User git IdentityFile ~/.ssh/_id_rsa IdentitiesOnly yes

Assurez-vous maintenant que ce ~/.ssh/_id_rsan'est pas le cas en ssh-agentexécutant ssh-add -D. Cette commande supprimera toutes les clés de la ssh-agentsession actuellement active . La session est réinitialisée à chaque fois que vous vous déconnectez ou redémarrez (ou si vous arrêtez le ssh-agentprocessus manuellement). Nous pouvons «simuler» le redémarrage en exécutant la commande mentionnée.

Si vous essayez de cloner votre référentiel GitHub maintenant, ce sera la même chose que si nous ajoutions la clé manuellement (comme nous l'avons fait auparavant). Un mot de passe vous sera demandé:

git clone [email protected]:steve/raspberry-spy.git Cloning into 'raspberry-spy'... Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

Vous aurez remarqué que la clé pour laquelle le mot de passe nous est demandé est la même que celle que nous avons spécifiée dans notre configfichier. Après avoir entré le mot de passe de clé SSH correct, le référentiel sera cloné avec succès.

Remarque: si, après un clonage réussi, vous essayez git pull, vous serez à nouveau invité à saisir le mot de passe. Nous résoudrons cela plus tard.

Il est important que Host github.comde configet à github.compartir de l'URI [email protected]:steve/raspberry-spy.gitcorrespondent. Vous pouvez également changer configpour être Host mygithubet cloner à l'aide de l'URI [email protected]:steve/raspberry-spy.git.

This opens the floodgates. As you are reding this, your mind is racing and thinking about how all your troubles with SSH keys are over. Here are some useful configuration examples:

Host bitbucket-corporate HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_corp IdentitiesOnly yes

Now you can use git clone [email protected]:company/project.git

Host bitbucket-personal HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes

Now you can use git clone [email protected]:steve/other-pi-project.git

Host myserver HostName ssh.steve.com Port 1111 IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes User steve IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. How cool is that? You do not need to enter port and username manually every time you execute ssh command.

Bonus: Per-repository settings

You can also define which specific key should be used for certain repository, overriding anything in SSH config. Specific SSH command can be defined by setting sshCommand under core in /.git/config. Example:

[core] sshCommand = ssh -i ~/.ssh/id_rsa_corp

This is possible with git 2.10 or later. You can also use this command to avoid editing the file manually:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Password managemet

Last piece of the puzzle is managing passwords. We want to avoid having to enter password every time when SSH connection is initiating. To do so, we can utilize keychain management software that comes with MacOS and various Linux distributions.

Start by adding your key to the keychain by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in the keychain. On MacOS it looks something like this:

Keychain Access

If you remove the keys from ssh-agent via ssh-add -D (this will happen when you restart your computer, as mentioned before) and try SSH-ing, you will be prompted for password again. Why? We just added the the key to the keychain. If you check Keychain Access again, you will notice that the key you added using ssh-add -K is still in the keychain. Weird, huh?

It turns out there is one more hoop to jump through. Open your SSH config file and add the following:

Host * AddKeysToAgent yes UseKeychain yes

Now, SSH will look for key in keychain and if it finds it you will not be prompted for password. Key will also be added to ssh-agent. On MacOS this will work on MacOS Sierra 10.12.2 or later. On Linux you can use something like gnome-keyring and it might work even without this last modification to SSH config. As for Windows - who knows, right?

I hope someone found this useful. Now go and configure your SSH config file!

Learn more about SSH:

  • The ultimate guide to SSH keys
  • A top-down introduction to SSH