SSH deploy sin contraseña con llaves de despliegue
Dedicados & VPS
23

SSH deploy sin contraseña con llaves de despliegue

Cuando automatizas el despliegue de un sitio, llega un momento incómodo: tu script necesita clonar o hacer pull desde un repositorio privado, pero no puedes dejar una contraseña escrita en el servidor. La solución profesional son las deploy keys, llaves SSH dedicadas exclusivamente a tareas de despliegue.

¿Qué es una deploy key?

Es un par de llaves SSH (pública y privada) que creas específicamente para un servidor y un repositorio. La llave pública se registra en GitHub, GitLab o Bitbucket asociada a un repo, normalmente con permisos de solo lectura. La privada vive en el servidor y permite que este descargue el código sin pedir contraseña, pero no puede hacer nada más.

Ventajas sobre usar tu llave personal

  • Si tu llave personal se filtra, un atacante puede acceder a todos tus repositorios. Una deploy key solo afecta a uno.
  • Puedes darle permisos de solo lectura. Así, aunque alguien la robe, no puede pushear código malicioso.
  • Si dejas la empresa o revocas tu cuenta, el despliegue sigue funcionando porque la llave pertenece al servidor, no a ti.
  • Es trivial rotarlas: borras la vieja, creas una nueva y reemplazas.

Generar la llave en el servidor

Conéctate por SSH y ejecuta:

ssh-keygen -t ed25519 -C "deploy-misitio" -f ~/.ssh/deploy_misitio

Cuando te pida la passphrase, déjala vacía (si el servidor la pide cada vez que despliega, no sirve para automatizar). Esto crea dos archivos: deploy_misitio (privada) y deploy_misitio.pub (pública).

Registrar la llave pública en GitHub o GitLab

Muestra el contenido de la llave pública:

cat ~/.ssh/deploy_misitio.pub

Copia toda la línea. En GitHub entra a tu repositorio, ve a Settings → Deploy keys → Add deploy key, pega el contenido y no marques la casilla de permisos de escritura. En GitLab se llama Deploy Keys y el proceso es idéntico. En Bitbucket, Access keys.

Configurar ~/.ssh/config para múltiples repos

Como cada repo usa una llave distinta, necesitas decirle a SSH qué llave usar para cada conexión. Edita o crea ~/.ssh/config:

Host github-misitio
    HostName github.com
    User git
    IdentityFile ~/.ssh/deploy_misitio
    IdentitiesOnly yes

Host github-tienda
    HostName github.com
    User git
    IdentityFile ~/.ssh/deploy_tienda
    IdentitiesOnly yes

Ahora, en lugar de clonar con la URL normal, usas el alias:

git clone git@github-misitio:tuusuario/misitio.git

SSH detecta que el host es un alias, usa la llave correcta y GitHub responde como si fuera una conexión normal. Puedes tener tantos alias como necesites en el mismo servidor, cada uno apuntando a un repo distinto sin mezclar permisos.

Buenas prácticas

Guarda las llaves con permisos estrictos: chmod 600 ~/.ssh/deploy_*. Documenta qué llave sirve a qué servicio. Rota las llaves al menos una vez al año o cuando cambie el equipo. Y nunca, bajo ninguna circunstancia, copies una deploy key a tu laptop personal: su razón de existir es quedarse donde la generaste.