Cómo tener varios repositorios con misma clave SSH en Github

Me ha pasado más de una vez: vas a añadir una clave SSH en un repo nuevo, la pegas en Deploy Keys, le das a guardar y GitHub te suelta un escueto «Key is already in use», sin más contexto. Y tú ahí, mirando la pantalla, pensando «pero si es la misma clave que uso siempre, ¿por qué me la rechaza ahora?».

Pues resulta que no es un bug ni un capricho de GitHub, es una limitación intencionada. Y una vez entiendes por qué pasa, el resto encaja solo.

Deploy key no es lo mismo que tu clave de cuenta

Aquí está el lío de fondo, y es el primer concepto que hay que separar bien:

• Una deploy key es una clave SSH atada a un único repositorio. GitHub no te deja reutilizar la misma deploy key en varios repos, cada uno necesita la suya propia. Es una medida de seguridad: si esa clave se compromete, el daño se queda limitado a ese repo, no se te cuela en todos los demás.
• Una clave SSH de cuenta, en cambio, va vinculada a tu usuario de GitHub entero, no a un repo concreto. Esa sí que te sirve para acceder a todos los repositorios a los que tengas permiso, sin tener que ir generando una clave nueva cada vez.

Así que si lo que quieres es poder clonar y hacer push en varios repos con la misma clave, lo que necesitas no es una deploy key, es meter esa clave en Settings > SSH and GPG keys de tu cuenta. Ahí es donde debería estar si la vas a usar de forma general.

Cuando de verdad necesitas claves distintas por repo o por cuenta

Ahora bien, hay un caso legítimo en el que sí quieres tener varias claves distintas: cuando trabajas con más de una identidad en la misma máquina. El típico ejemplo es tener una cuenta personal y otra del curro, y no querer mezclar los commits ni los accesos de una con la otra.

Para eso, la solución no son las deploy keys, es configurar tu ~/.ssh/config para que sepa qué clave usar según el alias que le indiques al clonar:

# Cuenta personal
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal
  IdentitiesOnly yes

# Cuenta laboral
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work
  IdentitiesOnly yes

Y luego, al clonar, usas el alias correspondiente en vez de github.com a secas:

git clone [email protected]:usuario/repositorio.git
git clone [email protected]:empresa/repositorio.git

No olvides cargar las dos claves privadas en tu agente SSH, o de nada sirve tenerlas bien configuradas en el archivo:

ssh-add ~/.ssh/id_rsa_personal
ssh-add ~/.ssh/id_rsa_work

El fallo típico que te vuelve a dar el mismo error

Ojo con una cosa, porque a mí me ha pillado más de una vez: si te dejas el IdentitiesOnly yes fuera de cada bloque Host, SSH puede probar primero tu clave por defecto (la que tengas cargada de forma general en el agente) antes que la que le has especificado para ese alias en concreto. Resultado: te vuelve a saltar el mismo lío de autenticación aunque tengas el .ssh/config perfectamente montado, y te quedas un buen rato sin entender por qué no coge la clave que le has puesto.

Con IdentitiesOnly yes le dices explícitamente a SSH «usa solo la que te indico aquí, no pruebes otras por tu cuenta», y ese es justo el detalle que suele faltar cuando alguien copia esta configuración de internet a medias.

Resumiendo

• Si el error es de una deploy key, revisa que no la estés intentando reutilizar en otro repo. Cada repo necesita la suya.
• Si lo que quieres es una clave que te sirva para todo, esa va en la config de tu cuenta, no como deploy key.
• Si trabajas con varias identidades en la misma máquina (personal y curro, por ejemplo), el ~/.ssh/config con alias es tu mejor amigo, pero no te olvides del IdentitiesOnly yes en cada bloque.

Si curráis con cuentas personales y de curro en la misma máquina, este .ssh/config os va a salvar más de un dolor de cabeza. A mí desde luego me lo ha salvado.