Inicio de sesión SSH con clave en Linux: claves ed25519 y desactivar contraseñas

Cualquier servidor con una IPv4 pública recibe ataques de fuerza bruta SSH a los pocos minutos de estar en línea, y el objetivo son los accesos con contraseña. Esta guía explica cómo configurar el inicio de sesión SSH con clave en Linux usando una clave ed25519 y después desactivar la autenticación SSH por contraseña sin quedarte fuera. Los pasos sirven para Debian 11/12, Ubuntu 20.04/22.04/24.04, CentOS 7 y Rocky Linux / AlmaLinux 8 y 9, tanto en un servidor cloud de JUSTG en Johannesburgo, Moscú, Tokio o Seúl como en un servidor dedicado.

Paso 1: Genera un par de claves SSH ed25519 en tu ordenador

La clave se crea en el equipo desde el que te conectas, nunca en el servidor. Las claves ed25519 son cortas, rápidas y compatibles con cualquier versión actual de OpenSSH. Una frase de contraseña protege la clave privada si pierdes el portátil, y ssh-agent la recuerda durante la sesión.

# On your own computer (Linux, macOS, or Windows 10/11 PowerShell)
ssh-keygen -t ed25519 -C "laptop-2026"
# Press Enter to accept ~/.ssh/id_ed25519, then set a passphrase

Obtendrás id_ed25519 (clave privada, no la compartas) e id_ed25519.pub (clave pública, la que se copia a los servidores).

Paso 2: Copia la clave pública al servidor

En Linux y macOS lo más cómodo es ssh-copy-id: entra una última vez con la contraseña y añade la clave a ~/.ssh/authorized_keys en el servidor.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Custom port example:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

Windows no incluye ssh-copy-id, pero desde PowerShell puedes enviar la clave con una tubería:

# Windows PowerShell (ssh-copy-id is not included on Windows)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Paso 3: Añade la clave manualmente y corrige los permisos de authorized_keys

Si prefieres pegar la clave tú mismo o trabajas desde la consola VNC, crea el archivo a mano. OpenSSH ignora sin avisar authorized_keys cuando el directorio o el archivo son modificables por otros usuarios, así que los permisos importan tanto como la clave.

# On the server, as the user that will log in
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys      # paste ONE key per line, then save
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
# CentOS / Rocky / AlmaLinux with SELinux enforcing:
restorecon -Rv ~/.ssh

Paso 4: Prueba el acceso SSH con clave antes de cambiar nada

Abre una terminal nueva y conéctate forzando solo la autenticación por clave. Si entras sin que se pida contraseña (salvo la frase de la clave), la clave funciona.

ssh -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]

Paso 5: Desactiva la contraseña SSH en sshd_config

Las distribuciones modernas cargan /etc/ssh/sshd_config.d/*.conf mediante una línea Include al inicio del archivo principal, y sshd se queda con el primer valor que lee de cada opción. Por eso un archivo como 50-cloud-init.conf con PasswordAuthentication yes puede anular en silencio tu cambio más abajo en sshd_config. Un archivo drop-in cuyo nombre se ordene primero lo evita.

# Check that the drop-in directory is included
grep -i '^Include' /etc/ssh/sshd_config

# Create a drop-in that sorts first (sshd keeps the FIRST value it reads)
cat > /etc/ssh/sshd_config.d/01-key-only.conf <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

# Look for files that still turn passwords back on (e.g. 50-cloud-init.conf)
grep -ri 'PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

En CentOS 7 y otros sistemas antiguos sin el directorio sshd_config.d, escribe esas cuatro líneas directamente en /etc/ssh/sshd_config y comenta cualquier PasswordAuthentication yes anterior. PermitRootLogin prohibit-password deja entrar a root solo con clave; usa no si accedes con un usuario sudo normal.

Paso 6: Valida la configuración SSH y recarga el servicio

# Validate syntax first - no output means OK
sshd -t
# Show the effective values
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractive'

# Debian / Ubuntu
systemctl reload ssh
# CentOS / Rocky / AlmaLinux
systemctl reload sshd

La recarga mantiene tu sesión abierta, pero la prueba solo está a medias.

Paso 7: Comprueba en una segunda sesión antes de cerrar la primera

# From a NEW terminal on your computer
ssh [email protected]
# Must be refused:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
# Expected: Permission denied (publickey).

Si algo falla, corrige el archivo drop-in desde la primera sesión, que sigue abierta, y recarga de nuevo. Si ya perdiste el acceso, entra en el área de clientes de JUSTG → Mis productos y servicios → selecciona el VPS → panel de gestión y usa la consola VNC; si no la encuentras, abre un ticket.

Preguntas frecuentes

¿Es mejor ed25519 que RSA para claves SSH?

Para claves nuevas, sí: ofrece gran seguridad con una clave mucho más corta y conexiones más rápidas. Usa RSA 4096 solo si debes conectar con sistemas muy antiguos sin soporte para ed25519.

Sigue pidiéndome contraseña, ¿por qué?

Ejecuta sshd -T | grep -i passwordauthentication. Si muestra yes, otro archivo de sshd_config.d se lee antes que el tuyo. Revisa también /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (Rocky/AlmaLinux) en busca de «bad ownership or modes» sobre ~/.ssh.

¿Puedo usar la misma clave en varios servidores de JUSTG?

Sí, copia la misma clave pública a cada servidor con ssh-copy-id. Guarda la clave privada solo en tus dispositivos y, si pierdes uno, elimina su línea de authorized_keys.

Si sigues sin poder entrar con tu clave SSH, abre un ticket en https://www.justg.com/submitticket.php y el soporte técnico de JUSTG te ayudará.