Cómo administrar varias claves SSH

Es seguro decir que la mayoría de los desarrolladores en la esfera web se han encontrado en algún momento con SSH. SSH es uno de los protocolos más utilizados para el intercambio seguro de datos. Usas SSH para conectarte a servidores remotos, lo que también incluye administrar tu código usando Git y sincronizar con repositorios remotos.

Aunque se considera una buena práctica tener un par de claves públicas y privadas por dispositivo, a veces es necesario utilizar varias claves y / o tiene nombres de claves poco ortodoxos.

Es posible que esté usando un par de claves SSH para trabajar en los proyectos internos de su empresa, pero es posible que esté usando una clave diferente para acceder a los servidores de algunos clientes corporativos. Incluso podría estar usando una clave diferente para acceder a su propio servidor privado.

La administración de claves SSH puede resultar engorrosa tan pronto como necesite utilizar una segunda clave. Espero que este artículo sea de ayuda para cualquiera que tenga problemas con la administración de claves SSH.

Supongo que el lector tiene conocimientos básicos de Git y SSH. La mayoría de los ejemplos a lo largo del artículo usarán Git. Por supuesto, todo esto se aplicará a cualquier otra comunicación SSH. Dicho esto, se incluyen algunos trucos específicos de Git.

Abróchate el cinturón, ¡aquí vamos!

Tratar con una clave SSH

Primero, veamos cómo se vería su flujo de trabajo antes de tener varias claves de las que preocuparse.

Tiene una clave privada almacenada ~/.ssh/id_rsacon una clave pública correspondiente ~/.ssh/id_rsa.pub.

Imaginemos que desea enviar / extraer cambios de código hacia / desde un servidor Git remoto; digamos GitHub, ¿por qué no? Para hacerlo, primero debe agregar su clave pública a GitHub.

No repasaré ese paso, debería ser bastante fácil descubrir cómo hacerlo. También asumí que su nombre es Steve y está trabajando en un proyecto de alto secreto que usa Raspberry Pies para rastrear el tráfico de la red.

Para comenzar su trabajo, debe clonar un repositorio de git usando SSH:

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

En este momento, GitHub será como: “¡Este es un repositorio privado! Necesitamos cifrar el tráfico con esta clave pública que tengo aquí y su clave privada ".

Ha agregado la clave pública a su perfil en GitHub, pero SSH tiene que averiguar de alguna manera dónde se encuentra su clave privada correspondiente.

Como no tenemos ni idea de qué clave privada se debe usar cuando se ingresa a [email protected]SSH, el cliente SSH intenta encontrar una clave en la ubicación predeterminada, que es ~/.ssh/id_rsasu mejor suposición. Si no hay ningún archivo en esa ubicación, obtendrá un error:

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 tiene alguna clave privada almacenada en un archivo ~/.ssh/id_rsa, el cliente SSH usará esa clave privada para el cifrado de la comunicación. Si esa clave tiene una contraseña (como debería ser), se le pedirá una contraseña, así:

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

Si ingresa la contraseña correcta y si esa clave privada es la que corresponde a la clave pública que adjuntó a su perfil, todo irá bien y el repositorio se clonará con éxito.

Pero, ¿qué pasa si nombró su clave de manera diferente (por ejemplo ~/.ssh/_id_rsa)? El cliente SSH no podrá determinar dónde se almacena la clave privada. Obtendrá el mismo Permission denied ...error que antes.

Si desea usar una clave privada que nombró de manera diferente, debe agregarla manualmente:

ssh-add ~/.ssh/_id_rsa

Después de ingresar la frase de contraseña, puede verificar si la clave se agregó a ssh-agent(cliente SSH) ejecutando ssh-add -l. Este comando enumerará todas las claves que están disponibles actualmente para el cliente SSH.

Si intenta clonar el repositorio ahora, tendrá éxito.

¿Hasta aquí todo bien?

Si tiene buen ojo, puede comenzar a notar algunos problemas potenciales.

En primer lugar, si reinicia su computadora, ssh-agentse reiniciará y tendrá que agregar sus claves con nombres no predeterminados usando ssh-addtodo de nuevo, escribiendo contraseñas y todas esas cosas tediosas.

¿Podemos automatizar la adición de claves o especificar de alguna manera qué clave usar al acceder a ciertos servidores?

¿Podemos guardar las contraseñas de alguna manera para no tener que escribirlas todo el tiempo? Si tan solo hubiera algo como un llavero para guardar claves SSH protegidas por contraseña.

Tenga la seguridad de que hay respuestas a todas esas preguntas.

Entrar, SSH config

Resulta que el archivo de configuración SSH es una cosa, algo que puede ayudarnos. Es un archivo de configuración por usuario para la comunicación SSH. Cree un nuevo archivo: ~/.ssh/configy ábralo para editarlo.

Administrar claves SSH con nombre personalizado

Lo primero que vamos a resolver usando este configarchivo es evitar tener que agregar claves SSH con nombre personalizado usando ssh-add. Suponiendo que su clave SSH tiene un nombre ~/.ssh/_id_rsa, agregue lo siguiente al configarchivo:

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

Ahora asegúrese de que ~/.ssh/_id_rsano esté en ssh-agentejecutando ssh-add -D. Este comando eliminará todas las claves de la ssh-agentsesión actualmente activa . La sesión se restablece cada vez que cierra sesión o reinicia (o si mata el ssh-agentproceso manualmente). Podemos "simular" el reinicio ejecutando el comando mencionado.

Si intenta clonar su repositorio de GitHub ahora, será lo mismo que si agregamos la clave manualmente (como lo hicimos antes). Se le pedirá la contraseña:

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

Habrá notado que la clave cuya contraseña se nos solicita es la misma clave que especificamos en nuestro configarchivo. Después de ingresar la contraseña de clave SSH correcta, el repositorio se clonará con éxito.

Nota: si, después de la clonación exitosa, lo intenta git pull, se le solicitará la contraseña nuevamente. Lo resolveremos más tarde.

Es importante que coincida Host github.comdesde configy github.comhacia URI [email protected]:steve/raspberry-spy.git. También puede cambiar configde ser Host mygithuby el clon usando 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