Ubuntu 22.04 Server / Iniciar sesión como root localmente y por SSH

En Ubuntu 22.04 Server, lo habitual para trabajar con privilegios de root es entrar con una cuenta normal y ejecutar sudo -i. El acceso directo como root requiere comprobar por separado la contraseña y la política de inicio de sesión; SSH depende también de PermitRootLogin y los métodos de autenticación.

Privilegios de root y acceso directo

Root es la cuenta que administra todo el sistema. Ubuntu bloquea su contraseña de forma predeterminada y permite a usuarios autorizados ejecutar sudo con sus propias credenciales. La cuenta root sigue existiendo. Consulta la documentación de usuarios de Ubuntu para conocer este diseño.

Si solo necesitas una consola administrativa, usa los comandos siguientes. La autenticación suele emplear la contraseña de la cuenta normal, según la política sudo. Comprueba que whoami muestra root y vuelve a la cuenta normal con exit al terminar. Esto no activa la contraseña de root ni cambia la política SSH.

sudo -i
whoami
exit

Define una contraseña de root aparte solo si necesitas acceso por contraseña en la consola o cambiar con su -. La primera petición sudo corresponde a tu cuenta normal; las dos siguientes definen la nueva contraseña de root. Los caracteres no aparecen mientras escribes.

sudo passwd root
su -
whoami
exit

su - usa la contraseña de root recién definida. Definirla no permite automáticamente todos los accesos: PAM (Pluggable Authentication Modules, módulos de autenticación conectables) y las políticas de consola o acceso remoto pueden restringirlos. El manual de sudo de Ubuntu 22.04 explica sudo -i.

Revisar el acceso y la política SSH existente

Este procedimiento trata OpenSSH en un servidor Ubuntu 22.04 que administras. Mantén abierta la sesión SSH de la cuenta normal y prepara una consola física o de recuperación en la nube. En producción, considera primero una cuenta normal seguida de sudo. Si necesitas root directo, decide también el uso de claves públicas y la red de administración permitida.

Si falta el servidor SSH, ejecuta sudo apt update y después sudo apt install openssh-server. Revisa el servicio con sudo systemctl status ssh.service. Necesitas la dirección y el puerto reales; el cortafuegos y las reglas de la nube deben permitir esa conexión administrativa.

Copia la configuración y localiza las directivas antes de modificarlas. Si el nombre de copia ya existe, elige otro para no sobrescribirlo. Guarda las copias fuera de los directorios cargados mediante *.conf, como en el ejemplo.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

El archivo del servidor es sshd_config, distinto del ssh_config del cliente. Ubuntu 22.04 suele cargar primero /etc/ssh/sshd_config.d/*.conf. La mayoría de directivas usa el primer valor obtenido, así que añadir una línea al final quizá no sustituya otra anterior. Examina el orden de Include, las condiciones Match y los archivos de la nube; verifica los valores efectivos.

Según el manual sshd_config de Ubuntu 22.04, PermitRootLogin yes permite root si se cumplen las demás condiciones. prohibit-password impide contraseña y autenticación interactiva de teclado para root, pero puede permitir claves públicas. no prohíbe root por SSH. Una línea predeterminada comentada no determina por sí sola la política real.

Configurar SSH de root con contraseña

Este método expone la autenticación de la contraseña de root; úsalo solo si el entorno administrativo lo necesita. Define la contraseña con sudo passwd root y edita la configuración que realmente tiene prioridad mediante sudoedit /etc/ssh/sshd_config o el fragmento correspondiente. Lo siguiente es un ejemplo de política, no una indicación de añadir líneas sin revisar al final.

PermitRootLogin yes
PasswordAuthentication yes

PermitRootLogin yes no basta. La autenticación por contraseña, AuthenticationMethods, restricciones de usuarios o grupos, PAM y estado de la cuenta también deben permitir el acceso. Un PasswordAuthentication yes global puede afectar a otros usuarios; revisa si amplía la política. No desactives el cortafuegos ni elimines la autenticación multifactor para seguir esta guía.

Guardar el archivo no termina la aplicación. Realiza la validación y recarga descritas más abajo antes de probar desde el cliente. Sustituye 192.0.2.20 por la dirección real. Para otro puerto distinto del 22 predeterminado, usa ssh -p PORT con el número correcto.

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20

Esta prueba elige contraseña en lugar de clave pública. Una contraseña sola no funciona si se exige autenticación adicional. Verifica la huella de la clave del host por un canal administrativo fiable; no desactives la comprobación para evitar una advertencia de cambio de clave.

Usar una clave pública para SSH de root

El cliente conserva la clave privada y el servidor solo registra la pública correspondiente. Activar el acceso de root por contraseña no es un requisito. Puedes instalar la clave desde una sesión administrativa existente o una consola, sin abrir antes SSH de root con contraseña.

Si el cliente no tiene una clave adecuada, genérala con ssh-keygen -t ed25519. Elige un nombre nuevo para no sobrescribir otra clave y protege la privada con una frase de paso. Registra la línea del archivo público ~/.ssh/id_ed25519.pub. Nunca copies al servidor la clave privada sin sufijo .pub.

En la sesión administrativa existente del servidor, prepara los permisos como se indica y añade la línea de clave pública con el editor. Conserva las claves existentes y evita duplicados. Si elegiste otro nombre de archivo, usa su clave pública correspondiente.

sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys

El ejemplo utiliza la ruta predeterminada de claves autorizadas. Comprueba la ruta real si AuthorizedKeysFile indica otra. Elige esta política para impedir la contraseña de root, resuelve directivas anteriores en conflicto y valida.

PermitRootLogin prohibit-password
PubkeyAuthentication yes

Tras validar y aplicar los ajustes del servidor, conecta desde el cliente como se indica. Si solicita la frase de paso de la clave privada, introduce la del cliente, no la contraseña de root. Las claves públicas también deben cumplir las políticas PAM, de cuenta y de acceso.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20

Validar la configuración y probar otra sesión

1. Primero comprueba la sintaxis y las claves del host en el servidor. Una comprobación -t correcta normalmente no genera salida. Si hay errores, corrige el archivo y la línea antes de recargar. -T muestra la configuración efectiva; con -C, evalúa las condiciones Match de la conexión indicada.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '

Sustituye 192.0.2.10 por la dirección del cliente administrativo vista por el servidor y admin.example por el nombre del cliente que se evalúa. Si utilizas Match LocalAddress o LocalPort, añade laddr y lport a -C. Si la salida no coincide, investiga primero prioridades y condiciones. Las opciones se explican en el manual sshd de Ubuntu 22.04.

2. Cuando la sintaxis sea correcta y los valores coincidan con la política prevista, recarga el servicio. Mantén abierta la sesión administrativa y prueba contraseña o clave en otra ventana del cliente.

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

3. Un servicio active no garantiza una autenticación nueva correcta. En la nueva sesión root, comprueba whoami igual a root e id -u igual a 0. Prueba también otra conexión normal y sudo. Las condiciones de usuario, clave, red o cuenta aún pueden denegar acceso.

Diagnosticar fallos y revertir el acceso root directo

Para Permission denied, revisa autenticación, cuenta y política de acceso. Para tiempo de espera o conexión rechazada, examina por separado dirección, puerto, servicio y cortafuegos. Usa sudo journalctl -u ssh.service -n 50 --no-pager en el servidor y ssh -v root@192.0.2.20 en el cliente. Oculta direcciones, usuarios y otros datos sensibles antes de compartir registros.

Para bloquear root por SSH de nuevo, cambia el PermitRootLogin efectivo a no, verifica sshd -t y sshd -T con las condiciones de conexión y ejecuta sudo systemctl reload ssh.service. Restaura también la política de contraseña alterada temporalmente. Revierte solo los archivos y opciones cambiados, sin sobrescribir todo el directorio de fragmentos.

Tras confirmar SSH y sudo con otra cuenta normal, bloquea la contraseña de root si la activaste para esta tarea y ya no la necesitas. Según el manual passwd, -l bloquea la contraseña, no todas las vías, como las claves públicas. Verifica el bloqueo SSH por separado con PermitRootLogin no.

sudo passwd -l root

Bloquear la contraseña o cambiar SSH no cierra automáticamente las sesiones root existentes. Termina el trabajo y sal de los shells root que abriste con exit. Si necesitas recuperar acceso, usa la sesión normal conservada o la consola de recuperación y restaura según las copias y el registro de cambios.