Si administras un servidor Linux, una Raspberry Pi o un VPS, tarde o temprano te conectarás a él por SSH. Escribir una contraseña cada vez es lento, y las contraseñas además son la parte más débil de la configuración. Las llaves SSH resuelven ambos problemas.

Esta guía explica qué es SSH y cómo funciona, y luego recorre cómo generar un par de llaves SSH, instalarlo en un servidor y desactivar los inicios de sesión con contraseña.

¿Qué Es SSH?

SSH (Secure Shell) es un protocolo de red que te permite iniciar sesión de forma segura y controlar una computadora remota a través de una red no confiable como internet. Funciona por defecto en el puerto TCP 22 y cifra todo lo que pasa por él: tu inicio de sesión, tus comandos y su salida.

SSH reemplazó a herramientas más antiguas como Telnet y rlogin, que enviaban todo en texto claro. Además de las sesiones de terminal remotas, SSH también se usa para:

  • Transferencia segura de archivos con SFTP y scp
  • Reenvío de puertos y túneles para llegar a servicios que están detrás de un firewall
  • Ejecutar comandos remotos y scripts de automatización
  • Operaciones de Git mediante URL del estilo [email protected]:

Cómo Funciona SSH

Una conexión SSH involucra dos partes: el cliente (tu computadora) y el servidor (la máquina remota que ejecuta un demonio SSH, sshd).

  1. Conexión y cifrado. El cliente y el servidor acuerdan los algoritmos de cifrado y crean una llave de sesión compartida, de modo que todo lo que sigue está cifrado.
  2. Verificación del servidor. El servidor demuestra su identidad con su llave de host. La primera vez que te conectas, tu cliente te pide confirmar la huella digital del servidor y la guarda en ~/.ssh/known_hosts. Si alguna vez cambia, recibes una advertencia, lo que te protege de la suplantación.
  3. Autenticación del usuario. Demuestras quién eres, ya sea con una contraseña o con una llave SSH.

Autenticación con Contraseña vs. con Llave SSH

ContraseñaLlave SSH
Lo que demuestrasAlgo que sabesLa posesión de un archivo de llave privada
Riesgo de fuerza brutaAlto, y los bots lo intentan constantementePrácticamente nulo
ComodidadSe escribe en cada inicio de sesiónSin escribir, o una frase de contraseña por sesión
AutomatizaciónIncómodaFácil para scripts y trabajos de CI

Cómo Funcionan las Llaves SSH

Una llave SSH es un par de archivos:

  • Una llave privada que se queda en tu computadora y nunca debe compartirse.
  • Una llave pública que se copia a cada servidor al que quieras acceder. Es seguro compartirla.

Cuando te conectas, el servidor usa tu llave pública para emitir un desafío que solo la llave privada correspondiente puede responder. Tu llave privada nunca sale de tu computadora, y nada secreto viaja por la red.

Paso 1: Genera un Par de Llaves SSH

En tu máquina cliente (Linux, macOS o Windows 10/11 con el cliente OpenSSH integrado), abre una terminal y ejecuta:

ssh-keygen -t ed25519 -C "[email protected]"

Ed25519 es un algoritmo moderno que es rápido, seguro y produce llaves cortas. Si necesitas ser compatible con sistemas muy antiguos, usa RSA:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Se te harán dos preguntas:

  1. Ubicación del archivo. Presiona Enter para aceptar la predeterminada (~/.ssh/id_ed25519).
  2. Frase de contraseña (passphrase). Establece una. Cifra tu llave privada en el disco, de modo que un archivo de llave robado no sirva por sí solo.

Esto crea dos archivos:

~/.ssh/id_ed25519       # llave privada (mantenla en secreto)
~/.ssh/id_ed25519.pub   # llave pública (compártela)

Paso 2: Copia la Llave Pública al Servidor

La forma más fácil en Linux y macOS es ssh-copy-id:

ssh-copy-id username@server-ip

Ingresa tu contraseña una última vez. El comando agrega tu llave pública a ~/.ssh/authorized_keys en el servidor y establece los permisos correctos.

En Windows (PowerShell)

ssh-copy-id no está disponible ahí, así que envía la llave por SSH con una tubería:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Método manual

Si ninguno de los dos funciona, inicia sesión con tu contraseña y agrega la llave a mano:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys     # pega el contenido de tu archivo .pub en una línea nueva
chmod 600 ~/.ssh/authorized_keys

Paso 3: Prueba el Inicio de Sesión con Llave

Conéctate de nuevo:

ssh username@server-ip

Si todo está bien configurado, iniciarás sesión sin la contraseña del servidor. Si estableciste una frase de contraseña, se te pedirá esa en su lugar, que solo desbloquea tu llave local.

Para usar una llave guardada en otro lugar, indícala con -i:

ssh -i ~/.ssh/my_other_key username@server-ip

Paso 4: Evita Volver a Escribir Tu Frase de Contraseña con ssh-agent

Una frase de contraseña mantiene tu llave segura, pero escribirla cada vez le quita la comodidad. El agente SSH mantiene tu llave desbloqueada en memoria durante la sesión:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

En macOS, puedes guardar la frase de contraseña en el llavero con ssh-add --apple-use-keychain ~/.ssh/id_ed25519. En Windows, el servicio ssh-agent puede configurarse para iniciarse automáticamente.

Paso 5: Agrega un Acceso Directo en la Configuración (Opcional)

En lugar de recordar usuarios, IPs y rutas de llaves, agrega una entrada a ~/.ssh/config en tu cliente:

Host myserver
    HostName 203.0.113.10
    User username
    IdentityFile ~/.ssh/id_ed25519

Ahora conectarse es simplemente:

ssh myserver

Paso 6: Deshabilita los Inicios de Sesión con Contraseña (Recomendado)

Una vez que el inicio de sesión con llave funcione, desactiva las contraseñas para que los atacantes no puedan entrar adivinando. Prueba primero el inicio de sesión con llave en una terminal aparte y mantén abierta tu sesión actual hasta confirmar que funciona.

En el servidor, edita la configuración del demonio SSH:

sudo nano /etc/ssh/sshd_config

Establece o cambia estas líneas:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Algunas distribuciones también incluyen archivos adicionales en /etc/ssh/sshd_config.d/ que pueden anular estos ajustes, así que revisa ahí si un cambio no surte efecto.

Valida el archivo y luego reinicia el servicio (ssh en Ubuntu/Debian, sshd en los sistemas basados en RHEL):

sudo sshd -t
sudo systemctl restart ssh

Solución de Problemas Comunes

  • Todavía te pide una contraseña. La causa habitual son los permisos. En el servidor, ~/.ssh debe ser 700 y authorized_keys debe ser 600, y tu directorio personal no debe poder ser modificado por otros.
  • “Permission denied (publickey)”. La llave pública no está en authorized_keys, o estás usando la llave o el usuario equivocados. Ejecuta ssh -v username@server-ip para ver una salida detallada.
  • “WARNING: UNPROTECTED PRIVATE KEY FILE!” Tu llave privada es demasiado abierta. Corrígelo con chmod 600 ~/.ssh/id_ed25519.
  • “REMOTE HOST IDENTIFICATION HAS CHANGED!” La llave de host del servidor difiere de la registrada. Si reconstruiste el servidor, elimina la entrada antigua con ssh-keygen -R server-ip. Si no lo hiciste, trátalo como un posible ataque.
  • Te quedaste fuera tras deshabilitar las contraseñas. Usa la consola web de tu proveedor de hosting o el modo de recuperación para volver a habilitar temporalmente PasswordAuthentication.

Mejores Prácticas para las Llaves SSH

  • Usa siempre una frase de contraseña en las llaves que viven en laptops o en máquinas compartidas.
  • Usa una llave distinta por dispositivo, para poder revocar una sin afectar a las demás.
  • Nunca compartas ni subas tu llave privada, y no incluyas archivos de .ssh en Git.
  • Elimina las llaves antiguas de authorized_keys cuando un dispositivo se retire o se pierda.
  • Agrega fail2ban o cambia las reglas del firewall si tu servidor está expuesto a intentos de inicio de sesión constantes.

Conclusión

SSH te da un canal cifrado para administrar máquinas remotas, y las llaves SSH hacen que ese canal sea más seguro y más rápido de usar. Genera un par de llaves Ed25519, copia la llave pública a tu servidor con ssh-copy-id, confirma que el inicio de sesión con llave funciona y luego deshabilita la autenticación con contraseña para cerrar la puerta a los ataques de fuerza bruta.

Una vez que te sientas cómodo con las llaves, la misma configuración funciona para las transferencias SFTP, el alojamiento de Git y la automatización, todo sin escribir una contraseña. Si quieres seguir avanzando, consulta Cómo Configurar un Servidor SFTP en Linux para transferir archivos de forma segura sobre la misma conexión SSH.