Paso 1: asegúrate de tener otra forma de entrar
Entra como usuario normal con tu clave, en una ventana que mantengas abierta, y comprueba que sudo funciona:
ssh user@server
sudo -vSi todavía no tienes esa cuenta, mira cómo crear un usuario SSH con sudo. Hazlo primero. Es el único paso que te protege de quedarte fuera.
Paso 2: busca ajustes que ya existan
sudo grep -ri permitrootlogin /etc/ssh/sshd_config /etc/ssh/sshd_config.d/En la mayoría de los ajustes de sshd, gana el primer valor que se lee, no el último. En Debian y Ubuntu, sshd_config tiene Include /etc/ssh/sshd_config.d/*.conf cerca del principio, así que los archivos de esa carpeta se leen primero, por orden de nombre. En nuestra prueba, con 00-cloud.conf diciendo PermitRootLogin yes y 10-no-root.conf diciendo no, root siguió permitido.
La imagen de un proveedor de hosting puede traer un archivo así, así que elimina o cambia cualquier línea de ese tipo. Sin línea Include, edita PermitRootLogin en el propio sshd_config.
Paso 3: añade el ajuste
echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/10-no-root.confPaso 4: comprueba antes de recargar
sudo sshd -t
sudo sshd -T | grep -i permitrootloginsshd -t no imprime nada cuando todo está bien. Un error tipográfico da un mensaje como unsupported option "maybe", y debes corregirlo antes de seguir. sshd -T muestra el valor que el servidor usará de verdad:
permitrootlogin noPaso 5: recarga
# Debian and Ubuntu
sudo systemctl reload ssh
# Red Hat, Fedora and similar
sudo systemctl reload sshdUna recarga se aplica a las conexiones nuevas, y tu sesión abierta continúa. Lo confirmamos: una sesión abierta antes del cambio siguió funcionando, y un acceso nuevo siguió la regla nueva.
Paso 6: prueba desde una ventana nueva
ssh root@serverDeberías ver Permission denied, incluso con la clave correcta. El registro del servidor dice:
ROOT LOGIN REFUSED FROM 203.0.113.10 port 41288Después entra con tu usuario normal desde otra ventana nueva y ejecuta sudo -v otra vez.
Qué hace cada valor
| Valor | Contraseña | Clave | Clave con comando forzado |
|---|---|---|---|
yes | Permitido | Permitido | Permitido |
prohibit-password | Rechazado | Permitido | Permitido |
forced-commands-only | Rechazado | Rechazado | Permitido |
no | Rechazado | Rechazado | Rechazado |
El valor por defecto es prohibit-password, desde OpenSSH 7.0. Así, en un sistema que no lo ha cambiado, root no puede entrar con contraseña, pero una clave de root sí funciona. without-password es un nombre antiguo del mismo valor. sshd -T imprimió without-password en nuestro servidor OpenSSH 10.0 cuando el ajuste era prohibit-password. La versión 10.1 cambió eso para imprimir el nombre actual.
Un comando forzado es command="..." en authorized_keys. forced-commands-only sirve para un trabajo de copia de seguridad que de verdad necesita root para un único comando fijo.
Excepciones con Match
Para permitir claves de root solo desde una dirección de gestión, añade esto al mismo archivo, debajo de la primera línea:
Match Address 203.0.113.10
PermitRootLogin prohibit-passwordEl sshd -T simple no muestra el efecto de un bloque Match. Usa -C para describir una conexión y ver qué se aplicaría. Estos dos dieron respuestas distintas en nuestra prueba:
sudo sshd -T -C user=root,host=server,addr=203.0.113.10 | grep -i permitrootlogin
sudo sshd -T -C user=root,host=server,addr=198.51.100.7 | grep -i permitrootloginSi te quedas fuera
Usa la consola de tu proveedor de hosting, que no pasa por SSH. Borra el archivo que añadiste y recarga sshd.
Preguntas
¿Qué diferencia hay entre PermitRootLogin no y prohibit-password?
no rechaza a root de cualquier forma. prohibit-password, el valor por defecto, rechaza la contraseña de root pero sigue aceptando una clave de root.
¿Recargar sshd cierra mi sesión abierta?
No. La recarga se aplica a las conexiones nuevas, y las sesiones ya abiertas siguen.
¿Y si me quedo fuera tras desactivar root?
Usa la consola web de tu proveedor, que no pasa por SSH. Borra el archivo que añadiste y recarga sshd.