Start typing to search across invoices, services, domains, tickets, and more...
A diferencia de las contraseñas, las claves SSH son prácticamente imposibles de descifrar por fuerza bruta y, combinadas con la desactivación del inicio de sesión con contraseña, mejoran mucho la seguridad del servidor y le permiten iniciar sesión sin escribir una contraseña. Esta guía explica paso a paso cómo configurar el inicio de sesión con clave SSH en Linux: generar una clave ed25519 en su equipo con ssh-keygen, subir la clave pública, corregir los permisos de authorized_keys y, una vez verificado, desactivar la autenticación por contraseña. Los comandos del servidor sirven para Debian/Ubuntu y CentOS/Rocky/AlmaLinux; el cliente puede ser Windows, macOS o Linux.
Ejecute lo siguiente en su propio equipo, no en el servidor. Las claves ed25519 son cortas, seguras y rápidas, y son el algoritmo recomendado hoy en día. Puede definir una frase de contraseña (passphrase) para que la clave privada sea inútil aunque el archivo se filtre; pulse Enter para omitirla.
# Funciona en terminales de macOS/Linux y en Windows PowerShell
ssh-keygen -t ed25519 -C "me@my-laptop"
# Resultado:
# ~/.ssh/id_ed25519 clave privada - no la comparta nunca
# ~/.ssh/id_ed25519.pub clave pública - se copia al servidor
En macOS y Linux, ssh-copy-id añade la clave pública a ~/.ssh/authorized_keys en el servidor y configura los permisos por usted. Se le pedirá la contraseña del servidor una vez.
# macOS / Linux
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected] # custom port
El cliente OpenSSH integrado en Windows no incluye ssh-copy-id. En PowerShell, este comando hace lo mismo:
# Windows PowerShell (sin ssh-copy-id)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
sshd es estricto: si ~/.ssh o authorized_keys tienen permisos demasiado abiertos, la clave se ignora sin avisar. Ejecute estos comandos en el servidor si añadió la clave manualmente. En sistemas con SELinux, restaure también el contexto de seguridad.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R root:root ~/.ssh
# CentOS / Rocky / AlmaLinux con SELinux: restaurar el contexto correcto
restorecon -Rv ~/.ssh
Mantenga abierta su sesión actual y haga la prueba desde una nueva terminal local. Si ya no se le pide la contraseña del servidor (solo la frase de contraseña de la clave, si la definió), el inicio de sesión con clave funciona.
# Desde su equipo: debería iniciar sesión sin pedir la contraseña del servidor
ssh -i ~/.ssh/id_ed25519 [email protected]
Cuando el inicio de sesión con clave funcione, edite /etc/ssh/sshd_config para desactivar la autenticación por contraseña. PermitRootLogin prohibit-password permite que root inicie sesión solo con claves. Muchas imágenes en la nube incluyen un archivo adicional en /etc/ssh/sshd_config.d/ (por ejemplo, 50-cloud-init.conf) que vuelve a habilitar las contraseñas; modifíquelo también o la configuración principal no surtirá efecto.
# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
# Los archivos de sshd_config.d pueden sobrescribir el archivo principal: revíselos
grep -rn 'PasswordAuthentication' /etc/ssh/sshd_config.d/ 2>/dev/null
Compruebe la sintaxis con sshd -t y vea los valores efectivos con sshd -T. Cuando passwordauthentication muestre no, reinicie el servicio. Después, vuelva a probar el inicio de sesión con clave en una nueva ventana; ahora un intento de inicio de sesión con contraseña debería ser rechazado.
sshd -t
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin'
systemctl restart sshd # CentOS / Rocky / AlmaLinux / Debian
systemctl restart ssh # Ubuntu
Normalmente los permisos son incorrectos o la clave se pegó mal. Asegúrese de que cada clave pública ocupe una sola línea en authorized_keys y de que los permisos sean 700/600, y ejecute ssh -v para ver si el cliente ofrece la clave correcta.
Genere una clave en cada equipo y añada cada clave pública en su propia línea de authorized_keys. Si pierde un equipo, basta con eliminar su línea.
Inicie sesión a través de la consola VNC del área de cliente con la contraseña de root (la consola no se ve afectada por la configuración de SSH) y añada una nueva clave pública. Si también olvidó la contraseña de root, abra un ticket de soporte.
¿Sigue con problemas después de seguir estos pasos? Abra un ticket de soporte y el equipo técnico 24/7 de IMIDC le ayudará. Incluya la IP del servidor, el sistema operativo, los comandos que ejecutó y una captura de pantalla del error para que podamos localizar el problema más rápido.