En el artículo anterior vimos que a la hora de conectar nuestro repositorio con la nube teníamos dos caminos: usar HTTPS o configurar SSH.
Ya digimos que SSH es la opción recomendada. Es más segura y, además, mucho más cómoda a largo plazo porque nos libra de gestionar tokens y contraseñas constantemente.
Configurar SSH requiere invertir cinco minutos para hacer una pequeña configuración entre tu ordenador y GitHub. Pero a cambio, Git no volverá a pedirte una contraseña.
¿Cómo funciona?
El protocolo SSH utiliza Criptografía Asimétrica. Es decir, en lugar de una contraseña, vamos a generar dos archivos vinculados matemáticamente:
- Clave Privada (
id_ed25519): Es TU LLAVE. Se guarda en tu ordenador. NUNCA se comparte. - Clave Pública (
id_ed25519.pub): Es LA CERRADURA. Se la puedes dar a cualquiera (en este caso, a GitHub).
Cuando intentas conectarte a GitHub, el servidor mira si la llave que tienes en tu bolsillo (Privada) encaja en la cerradura que le diste hace tiempo (Pública). Si encaja, te deja pasar sin preguntar nada más.
Hoy vamos a dejar tu ordenador configurado para conectarte con Git sin contraseñas, más seguro, y además más comodo. Vamos a ello. 👇
Paso 1: Generar el par de claves
Vamos a usar el algoritmo ed25519. Es el estándar moderno: es más rápido y genera claves más cortas y seguras que el antiguo RSA.
Ejecuta el siguiente comando (sustituyendo el correo por el tuyo, oooobviamente):
ssh-keygen -t ed25519 -C "[email protected]"
La terminal te hará algunas preguntas. Puedes pulsar Enter en todas para aceptar los valores por defecto:
File in which to save the key: Pulsa Enter (la guardará en ~/.ssh/id_ed25519).
Enter passphrase:
- Si dejas esto vacío (Enter), Git nunca te pedirá contraseña. Es lo más cómodo.
- Si escribes una contraseña, tendrás una capa extra de seguridad (si te roban el portátil, no podrán usar tu clave sin la frase), pero tendrás que escribirla cada vez (o configurar un agente).
Al finalizar, verás una imagen de “arte aleatorio” en la consola. Has creado tus claves.
Para este curso, te recomiendo dejarla vacía la passphrase, o usar una sencilla.
Paso 2: Copiar la clave pública
Ahora necesitamos coger la llave publica (la cerradura) para llevársela a GitHub.
Repito: Asegúrate de copiar el archivo que termina en .pub. Nunca compartas el archivo sin extensión.
Puedes mostrar el contenido en la terminal y copiarlo con el ratón:
cat ~/.ssh/id_ed25519.pub
El contenido será una línea larga que empieza por ssh-ed25519 AAAA... y termina con tu email. Cópialo todo.
Paso 3: Añadir la clave a GitHub / GitLab
Ahora vamos a decirle al servidor “Esta es mi cerradura”.
Ve a github.com y entra en tu cuenta.
Haz clic en tu foto de perfil (arriba a la derecha) Settings.
En el menú lateral izquierdo, busca SSH and GPG keys.
Pulsa el botón verde New SSH key.
Title: Ponle un nombre para identificar tu ordenador (ej: “Portátil Luis”, “PC Casa”).
Key type: Déjalo en “Authentication Key”.
Key: Pega el contenido que copiaste en el paso anterior.
Dale a Add SSH key.
Ve a tus preferencias de usuario.
En el menú lateral, busca SSH Keys.
Pega tu clave en el cuadro de texto “Key”.
El título se rellenará solo.
Pulsa Add key.
Probar la conexión
Ahora vamos a comprobar que todo funciona correctamente. Vamos a la terminal, e intenatmos conectar con GitHub por SSH.
ssh -T [email protected]
Si usas GitLab, sería ssh -T [email protected]
La primera vez que te conectes, verás un mensaje como este:
The authenticity of host ‘github.com’ can’t be established… Are you sure you want to continue connecting (yes/no/[fingerprint])?
Esto es normal. Tu ordenador te dice: “No conozco a este servidor, ¿te fías?”. Escribe yes y pulsa Enter. Si todo ha ido bien, verás un mensaje de éxito:
Hi TuUsuario! You’ve successfully authenticated, but GitHub does not provide shell access.
¡Felicidades! Ya estás conectado de forma segura.
Múltiples claves
Casi todos los tutoriales te dirán que aceptes el nombre por defecto (id_ed25519). Para empezar está bien, pero en el mundo real es una agujero de seguridad.
Si usas la misma llave para tu GitHub personal, el del trabajo y tus servidores, y te roban esa clave, tienen acceso a todas las apps. La práctica correcta es usar una clave diferente para cada entorno (una personal, otra para el trabajo, etc).
Generar claves con nombres específicos
En lugar de aceptar el nombre por defecto, vamos a decirle a Git exactamente cómo queremos que se llame cada archivo usando el parámetro -f.
# Para tu cuenta personal
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github_personal
# Para tu cuenta del trabajo
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github_trabajo
El archivo de configuración (config)
Ahora tienes varias llaves en tu carpeta ~/.ssh, pero tu ordenador no sabe cuál usar cuando intentas conectar con GitHub.
Para explicárselo, debemos crear (o editar) un archivo llamado config en esa misma carpeta. Dentro, vamos a crear “alias” (nombres inventados) para cada una de tus identidades:
# --- GITHUB PERSONAL ---
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/github_personal
IdentitiesOnly yes
# --- GITHUB TRABAJO ---
Host github-trabajo
HostName github.com
User git
IdentityFile ~/.ssh/github_trabajo
IdentitiesOnly yes
El parámetro IdentitiesOnly yes es fundamental. Le dice a tu cliente SSH que no intente probar a lo loco todas las claves que tengas en la carpeta, sino exclusivamente la que le estás indicando en ese bloque.
Usar tus alias al clonar
A partir de ahora, cuando vayas a trabajar con un repositorio, no uses la URL estándar que te da GitHub ([email protected]:usuario/repo.git).
Simplemente cambia la parte de github.com por el alias que has inventado en el paso anterior. Por ejemplo, para bajarte un proyecto de tu cuenta personal:
git clone git@github-personal:tu_usuario/tu_repo.git
Tu ordenador encuentra el texto github-personal, irá a leer el archivo config, entenderá que la dirección real del servidor es github.com y se autenticará usando únicamente la clave ~/.ssh/github_personal
