Claves SSH: cómo crearlas, elegir el tipo y desactivar contraseñas

Una clave SSH es un par de archivos: la clave privada se queda en tu ordenador y la pública va a ~/.ssh/authorized_keys en el servidor o al panel de control de tu hosting. Crea la clave con ssh-keygen -t ed25519, copia la parte pública con ssh-copy-id, prueba el acceso en una ventana nueva y solo entonces desactiva el inicio de sesión con contraseña. Después, comprueba siempre la configuración que realmente se aplica con sshd -T: en nuestro banco de pruebas, un archivo 50-cloud-init.conf mantenía las contraseñas activas sin avisar, aunque la comprobación de sintaxis no daba ningún error.

Resumen: de cero a entrar con clave

En tu propio ordenador (Linux, macOS o PowerShell en Windows 10 y 11, que ya incluyen el cliente OpenSSH):

ssh-keygen -t ed25519 -C "laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
ssh -i ~/.ssh/id_ed25519 user@server

El segundo comando pide una vez la contraseña del servidor y responde con Number of key(s) added: 1. En el banco de pruebas creó por sí solo ~/.ssh con permisos 700 y authorized_keys con permisos 600. Si nunca te has conectado a un servidor por SSH, empieza por nuestra guía sobre cómo conectarse por SSH desde Windows, macOS y Linux.

Ed25519, RSA o ECDSA: qué dicen las mediciones

Generamos claves de todos los tipos habituales e iniciamos sesión en el servidor 15 veces con cada una. Resultados:

La conclusión es sencilla: el tipo de clave no influye en la velocidad de inicio de sesión, las diferencias están dentro del ruido de medición. El tiempo de conexión se va en el intercambio de claves y en preparar la sesión, no en una sola firma. Lo que cambia es el tamaño y la comodidad: una clave pública Ed25519 es una línea corta, fácil de pegar en un panel o en un mensaje, mientras que una RSA 4096 llega a 700 caracteres y se rompe más a menudo al copiarla. Además, el tiempo de generación de RSA es aleatorio: diez generaciones de RSA 4096 tardaron entre 0,7 y 3,2 segundos.

Regla práctica:

• Ed25519 para cualquier clave nueva. Desde OpenSSH 9.5 es lo que crea ssh-keygen si omites -t; lo confirmamos en la 9.6.
• RSA 3072 o 4096 solo cuando un servidor o dispositivo no admite Ed25519: OpenSSH muy antiguo, algunos equipos de red, bibliotecas desactualizadas.
• ECDSA funciona, pero no aporta ninguna ventaja sobre Ed25519 en inicios de sesión normales.
• Las claves FIDO2 (ed25519-sk) guardan el secreto en un token físico y exigen tocarlo. Sin dispositivo, ssh-keygen -t ed25519-sk se detuvo en el banco con Key enrollment failed: device not found.

Frase de contraseña y ssh-agent

La frase de contraseña cifra la clave privada en el disco: si roban el archivo junto con tu portátil, sin la frase no sirve de nada. La opción -a fija el número de rondas de KDF, es decir, lo costoso que resulta adivinar la frase por fuerza bruta. Medimos cuánto tarda en descifrarse la clave:

• -a 16 (por defecto): 148 ms;
• -a 100: 1,0 s;
• -a 200: 2,0 s.

Un segundo para desbloquear apenas se nota cuando el agente descifra la clave una vez por jornada de trabajo:

ssh-keygen -t ed25519 -a 100 -C "work-laptop"
eval "$(ssh-agent -s)"
ssh-add -t 8h ~/.ssh/id_ed25519
ssh-add -l

Tras ssh-add, tres inicios de sesión seguidos se completaron sin ninguna pregunta. Sin agente, una clave con frase de contraseña no funciona de forma no interactiva: nuestro script recibió Permission denied (publickey,password). En Windows, el agente es un servicio que se activa una sola vez en un PowerShell con permisos de administrador: Get-Service ssh-agent | Set-Service -StartupType Automatic, después Start-Service ssh-agent y ssh-add.

Añadir la clave a un servidor, al panel y a PuTTY

Si no tienes ssh-copy-id (Windows no lo incluye), entra con tu contraseña y añade la clave a mano:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... laptop-2026" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Cada clave debe ocupar exactamente una línea. Cuando partimos la línea en dos, como ocurre al copiar desde una ventana estrecha, el servidor la rechazó sin avisar y el log solo decía Failed publickey. Puedes revisar el archivo con ssh-keygen -lf ~/.ssh/authorized_keys: muestra una huella por cada línea válida. sshd 9.6 aceptó sin problemas los finales de línea de Windows (CRLF).

Panel de control. En muchos paneles las claves SSH se añaden por usuario: en la configuración de la cuenta hay una sección para gestionar claves SSH, donde pegas la línea de tu archivo .pub. El panel la añade al authorized_keys de ese usuario. El acceso por SSH solo funciona si el usuario o su plan tiene una shell real en lugar de nologin. En un hosting compartido lo decide el proveedor, así que pregunta al soporte si SSH está activado para tu cuenta. En RichHost el acceso SSH está incluido en todos los planes.

PuTTY y FileZilla. PuTTY usa su propio formato .ppk. Probamos la conversión con puttygen 0.81:

puttygen ~/.ssh/id_ed25519 -o key.ppk
puttygen key.ppk -O public-openssh
puttygen key.ppk -O private-openssh -o id_from_ppk

El archivo recibió la cabecera PuTTY-User-Key-File-3, plink inició sesión con él y la huella coincidió con la clave original. Al revés no funciona: con un .ppk, OpenSSH respondió Load key "key.ppk": error in libcrypto. La misma clave sirve para SFTP; para configurar el cliente, consulta cómo conectar FileZilla al hosting.

~/.ssh/config y “Too many authentication failures”

Para no escribir cada vez el puerto, el usuario y la ruta de la clave, añade una entrada a ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    Port 22
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Ahora basta con ssh myserver, y ssh -G myserver muestra los valores que realmente se aplican. La línea IdentitiesOnly yes es importante: cargamos seis claves ajenas en el agente y nos conectamos con la clave correcta mediante -i. El cliente probó primero las claves del agente, y el servidor, con el valor por defecto MaxAuthTries 6, cortó la conexión con Too many authentication failures. Con IdentitiesOnly yes el inicio de sesión funcionó a la primera. El propio archivo de configuración también debe ser privado: con permisos 666 el cliente se negó a funcionar (Bad owner or permissions).

Permisos: lo que sshd llama “bad ownership or modes”

StrictModes yes (por defecto) hace que sshd ignore la clave si otros usuarios pudieran modificar los archivos. El cliente solo ve Permission denied (publickey); el motivo está en el log del servidor. Esto es lo que obtuvimos:

Un detalle propio de Ubuntu y Debian: sshd aceptó permisos 664 en authorized_keys y 775 en el directorio personal, porque el grupo era el grupo privado del usuario. En cuanto el archivo pasó a otro grupo con los mismos permisos 664, el acceso quedó bloqueado. La regla sencilla: ~/.ssh con 700, los archivos de dentro con 600 y tú como propietario. El cliente es todavía más estricto: ignora una clave privada con permisos 644 y muestra UNPROTECTED PRIVATE KEY FILE.

Desactivar el acceso con contraseña y comprobarlo con sshd -T

Mantén abierta tu sesión actual hasta que el acceso con clave funcione en una ventana nueva. Pon la configuración en un archivo aparte cuyo nombre quede ordenado antes que los demás:

# /etc/ssh/sshd_config.d/01-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
sudo systemctl reload ssh

En Ubuntu y Debian el servicio se llama ssh; en sistemas tipo RHEL es sshd. Por qué un archivo aparte con el prefijo 01: sshd usa el primer valor que encuentra para cada opción, y la línea Include está al principio de la configuración principal. Reprodujimos tres trampas en el banco:

1. 50-cloud-init.conf con PasswordAuthentication yes (cloud-init lo crea en muchas imágenes cloud) más nuestro propio 99-hardening.conf: sshd -t no informó de errores, sshd -T mostraba passwordauthentication yes y un inicio de sesión con contraseña funcionó.
2. PasswordAuthentication no añadido al final del sshd_config principal, como recomiendan muchas guías antiguas: el mismo resultado, las contraseñas seguían funcionando.
3. PasswordAuthentication no pero KbdInteractiveAuthentication yes con UsePAM yes: el servidor rechazó el método password, pero aceptó la misma contraseña por keyboard-interactive y registró Accepted keyboard-interactive/pam.

El archivo 01-hardening.conf resolvió los tres casos. Si tu configuración tiene bloques Match, prueba la conexión concreta: en nuestro caso sshd -T mostraba no, mientras que sshd -T -C user=deploy,host=x,addr=127.0.0.1 mostraba yes para una dirección incluida en Match Address. La lista completa de comprobaciones de la primera hora está en nuestra guía para configurar un VPS con Ubuntu.

Errores con claves SSH: causa y solución

Qué hacer en tu caso

En los planes de hosting compartido de RichHost los sitios se gestionan desde el panel de control propio con asistente de IA, y el soporte ayuda con las dudas de acceso de 10:00 a 20:00, hora de Kiev.

Preguntas frecuentes

¿Puedo usar una sola clave para todos los servidores?

Técnicamente sí, pero es mejor tener una clave por cada dispositivo desde el que te conectas. Así, perder el portátil significa borrar una línea de authorized_keys, no cambiar la clave en todas partes.

¿Dónde está la clave privada y puedo pasársela a un compañero?

En ~/.ssh (en Windows C:\Users\name\.ssh). No la compartas nunca: tu compañero crea su propio par de claves y tú añades su clave pública al servidor.

He desactivado las contraseñas y he perdido la clave. ¿Qué hago?

Entra por la consola web o el KVM del panel de tu proveedor, añade una clave pública nueva y recarga sshd. En un hosting compartido puedes volver a añadir una clave desde el panel o pedir ayuda al soporte.

¿Conviene cambiar el puerto 22?

Reduce el ruido en los logs, pero no es una protección. La protección real es el acceso solo con clave, con las contraseñas desactivadas y comprobado con sshd -T.