Claves SSH: por qué compartes la pública y nunca la privada

Si trabajas con WordPress, servidores o Git, usas claves SSH casi cada día. Haces un git push, te conectas al VPS de un cliente o despliegas un plugin desde GitHub Actions, y todo funciona. Pero si alguien te preguntara por qué funciona, y por qué hay dos claves en lugar de una, ¿sabrías explicarlo?

A ver, vamos a arreglarlo. En este post te cuento qué son las claves SSH, cómo se produce realmente la autenticación y qué hábitos te ayudan a mantener a salvo tus servidores y repositorios.

¿Qué es un par de claves SSH?

Cuando ejecutas ssh-keygen, tu ordenador no crea una clave. Crea un par de claves ligadas matemáticamente:

• La clave privada (por ejemplo id_ed25519). Se queda en tu máquina. Es tu identidad.
• La clave pública (por ejemplo id_ed25519.pub). La puedes compartir con quien quieras, publicarla o pegarla en cien servidores.

Esto se llama criptografía asimétrica. La propiedad clave es sencilla: lo que firmas con la privada se puede verificar con la pública, pero desde la pública no se puede calcular la privada.

La mejor analogía es un candado y su llave. La clave pública es el candado abierto: puedes repartir copias a todo el mundo y cada uno lo instala donde quiera. La clave privada es la única llave que lo abre, y nunca se la das a nadie.

Un malentendido muy común: no te conectas con la clave pública

Mucha gente dice "uso mi clave pública para conectarme". Es normal, porque copias la pública en GitHub o en el servidor. Pero los papeles son estos:

• La clave pública se instala en el servidor. Le dice: "esta persona tiene permiso para entrar".
• La clave privada la usas tú, en tu ordenador, para demostrar que eres esa persona.

El servidor tiene el candado. Tú tienes la única llave que lo abre.

Cómo funciona la autenticación SSH, paso a paso

Imagina que ejecutas este comando:

ssh david@mi-servidor.com

Esto es lo que pasa por detrás:

1. Tu cliente SSH le dice al servidor: "Soy david y tengo esta clave pública".
2. El servidor busca esa clave pública en ~/.ssh/authorized_keys. Si no está, te deniega el acceso.
3. Si está, te envía un reto: un dato aleatorio que es único para esta conexión.
4. Tu cliente firma ese dato con tu clave privada y devuelve la firma.
5. El servidor comprueba la firma con la clave pública. Si coincide, entras.

Fíjate en lo que nunca ocurre: tu clave privada no viaja por la red. Solo viaja una firma, y esa firma solo vale para esa sesión, así que nadie puede grabarla y reutilizarla más tarde.

Por qué dos claves son mejores que una contraseña

Con una contraseña, el secreto tiene que compartirse: lo sabes tú y lo sabe el servidor (o al menos un hash). Si el servidor sufre una filtración, o alguien intercepta tu login, el secreto queda expuesto.

Con un par de claves, el secreto vive en un único sitio: tu ordenador. Los servidores solo guardan claves públicas, que por sí solas no sirven para nada. Si un atacante roba todo el fichero authorized_keys, no consigue nada con lo que pueda hacerse pasar por ti.

Además escala mucho mejor. Si gestionas 30 servidores de clientes, no necesitas 30 contraseñas. Pones la misma clave pública en todos. Y cuando alguien del equipo se va, borras su línea de authorized_keys y listo, sin tener que rotar contraseñas.

El otro par de claves: la identidad del servidor

Hay una segunda parte menos conocida. El servidor también tiene su propio par de claves. La primera vez que te conectas, ves algo así:

The authenticity of host 'mi-servidor.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?

Ese mensaje es el servidor mostrándote la huella de su clave pública, para que compruebes que hablas con el servidor real y no con un impostor. Al aceptar, la clave se guarda en ~/.ssh/known_hosts. La próxima vez, si la clave cambia, SSH te avisa con un mensaje bien claro.

Es decir, la autenticación va en los dos sentidos: el servidor verifica quién eres tú con tu clave, y tú verificas quién es el servidor con la suya.

Ejemplos del día a día

• GitHub: pegas tu fichero .pub en Settings → SSH and GPG keys. Desde ese momento, cada git push se firma con tu clave privada.
• Despliegues con GitHub Actions: creas un par de claves exclusivo para desplegar. La pública va al servidor (o como deploy key en el repositorio) y la privada se guarda como secret cifrado. Si algún día se filtra, revocas solo esa.
• Servidores de clientes: tu clave pública está en el authorized_keys de cada servidor. Una identidad, muchos servidores y ninguna contraseña compartida.

Cómo generar un par de claves

Hoy el algoritmo recomendado es Ed25519. Es más rápido y corto que el clásico RSA, y muy seguro:

ssh-keygen -t ed25519 -C "tu@email.com"

SSH te preguntará dónde guardarla (la ruta por defecto, ~/.ssh/id_ed25519, está bien) y si quieres poner una passphrase. Después puedes copiar la clave pública a un servidor con:

ssh-copy-id david@mi-servidor.com

O mostrarla y pegarla donde la necesites, por ejemplo en GitHub:

cat ~/.ssh/id_ed25519.pub

Buenos hábitos para proteger tus claves

• Usa una passphrase. Si te roban el portátil, el fichero de la clave privada no sirve por sí solo. Con ssh-agent o el llavero del sistema solo la escribes una vez por sesión.
• No compartas nunca la clave privada. Ni por Slack, ni por email, ni en un repositorio Git, ni dentro de una imagen Docker. Si crees que se ha expuesto, genera un par nuevo y elimina la pública antigua de todos los sitios.
• Una clave por dispositivo. No copies la misma privada entre ordenadores. Si pierdes uno, revocas solo esa clave.
• Claves exclusivas para automatizaciones. Los pipelines de CI/CD deben tener sus propias claves, con los mínimos permisos necesarios.
• Revisa authorized_keys de vez en cuando. Elimina las claves de personas o máquinas que ya no necesitan acceso.

Resumen rápido

Un par de claves SSH es una clave pública que puedes dar a cualquiera y una clave privada que guardas solo para ti. El servidor almacena la pública, tú demuestras tu identidad firmando un reto con la privada, y el secreto nunca sale de tu ordenador. Por eso las claves SSH son más seguras que las contraseñas, más fáciles de gestionar con muchos servidores y la forma estándar de trabajar con Git y con máquinas remotas.

La próxima vez que hagas un git push, sabrás exactamente lo que ocurre por detrás.