Crear un usuario con permisos de sudo y dejar de trabajar como root

Cuando te entregan un servidor, entras como root, y root lo puede todo sin preguntar. Una errata afecta de inmediato a todo el sistema, y root es el único nombre de usuario que cualquier atacante conoce con seguridad. Esta guía recorre el camino completo: crear el usuario, meterlo en el grupo correcto, ampliar la configuración de sudoers, copiar la clave pública y solo al final cerrar el acceso root. La parte decisiva llega justo antes del final: la prueba de que no te has quedado fuera.

Los sistemas de referencia son Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS y Ubuntu 22.04 LTS. Donde los sistemas de la familia RHEL, como AlmaLinux y Rocky Linux, se comportan de otra manera, queda indicado. Los comandos están escritos para trabajar como root; si trabajas como usuario normal, antepón sudo a cada comando. La versión corta está en la checklist para servidores root nuevos, aquí viene la explicación a fondo.

Antes de cambiar nada: el camino de vuelta

Aquí hay dos cambios que te pueden costar el acceso: la configuración de sudoers y, al final del todo, el permiso para que root inicie sesión por SSH. Un archivo sudoers roto te quita los permisos, y un acceso root cerrado demasiado pronto te quita la vía alternativa. Por eso conviene dejar tres cosas resueltas antes.

Una segunda sesión. Abre una segunda ventana de terminal con una conexión SSH activa como root y no la cierres hasta haberlo comprobado todo. Una sesión ya establecida sobrevive tanto a un reinicio del servicio SSH como a un archivo sudoers defectuoso.

La vía que no pasa por SSH. En los servidores root KVM y en los servidores dedicados de KernelHost abres la consola VNC desde el área de cliente. Está conectada a la capa de virtualización o al propio puerto de la máquina, así que funciona con independencia de SSH, del firewall y del archivo sudoers. Entra ahí una vez antes de empezar: una vía de rescate que solo se prueba cuando ya hay una emergencia no es una vía de rescate.

Una contraseña que conozcas. La consola no entiende de claves SSH: ahí entras con nombre de usuario y contraseña, o no entras. De aquí sale la mayoría de los bloqueos.

Regla práctica: la vía de rescate es una consola, y una consola solo entiende contraseñas. Antes de desactivar el inicio de sesión por contraseña, al menos una cuenta tiene que tener una contraseña que conozcas.

Punto de partida: ¿está sudo instalado siquiera?

En las imágenes de servidor de Ubuntu, sudo viene incluido; en las imágenes mínimas de Debian, a menudo no. Tres líneas aclaran la situación de partida:

command -v sudo || echo "falta sudo"
getent group sudo
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd

La segunda línea muestra el grupo con sus miembros; la tercera, todas las cuentas normales con su identificador y su shell de inicio de sesión. En las imágenes con cloud-init suele existir desde hace rato una cuenta con permisos de sudo. Si falta sudo, lo instalas después:

apt-get update
apt-get install -y sudo
sudo -V | head -n 1

adduser o useradd: dos herramientas, dos resultados

Si usas useradd esperando el comportamiento de adduser, acabas con una cuenta sin directorio personal y con una shell con la que no contabas.

En Debian y Ubuntu, adduser es la opción correcta:

adduser --disabled-password --gecos "" kernel

--gecos "" se salta las preguntas por el nombre y los números de teléfono, y --disabled-password crea la cuenta sin contraseña. Aquí está la primera trampa: una cuenta sin contraseña no puede iniciar sesión en la consola VNC, y la petición de contraseña de sudo no se puede responder nunca con éxito. Por eso, asigna una contraseña justo después:

passwd kernel

En los sistemas de la familia RHEL, o dentro de un script, la versión equivalente es:

useradd -m -s /bin/bash kernel
passwd kernel

Comprobación:

getent passwd kernel
ls -ld /home/kernel
passwd -S kernel

getent passwd kernel muestra el directorio personal y la shell de inicio de sesión; si ahí aparece /bin/sh o /usr/sbin/nologin, lo corriges con usermod -s /bin/bash kernel. passwd -S kernel indica en la segunda columna el estado de la contraseña: P si es utilizable, L si está bloqueada y NP si no hay ninguna. Después de passwd kernel ahí tiene que poner P.

El grupo de administración: sudo en Debian y Ubuntu, wheel en RHEL

Un malentendido muy extendido: el grupo no concede los permisos por sí mismo, sino solo porque en /etc/sudoers hay una línea que se refiere a él. En Debian y Ubuntu esa línea viene a ser %sudo ALL=(ALL:ALL) ALL, y en los sistemas de la familia RHEL, %wheel ALL=(ALL) ALL. Lo que hay configurado en tu caso te lo enseña:

grep -E '^[^#]*%' /etc/sudoers

En Ubuntu aparece además una línea para el grupo histórico admin. Ese grupo ya no existe en las imágenes actuales, así que la línea no tiene ningún efecto. El usuario se añade así:

usermod -aG sudo kernel

La -a no es opcional. Sin esa opción, usermod -G sustituye todos los grupos secundarios por la lista que le indiques, sin decir nada, y el destrozo se suele descubrir semanas más tarde. La opción funciona únicamente junto con -G. Equivalente y menos propenso a errores es gpasswd -a kernel sudo.

Comprobación:

id -nG kernel
getent group sudo
sudo -l -U kernel

La última línea es la más reveladora: le pregunta al propio sudo. Lo esperado es un bloque que termine en (ALL : ALL) ALL. Si en su lugar sale User kernel is not allowed to run sudo on srv01., no se está aplicando ninguna regla.

Por qué el grupo nuevo no cuenta hasta el siguiente inicio de sesión

Un proceso recibe sus grupos en el momento del inicio de sesión y ya no vuelve a recibirlos después. Por eso id -nG kernel ejecutado como root muestra el grupo sudo, mientras que esa misma salida dentro de la sesión del usuario no lo incluye. Las dos cosas son correctas: un comando lee la base de datos de usuarios y el otro, la sesión en curso. La solución es volver a iniciar sesión, no reiniciar el servidor. newgrp sudo solo surte efecto en la shell exacta desde la que lo llamas.

Editar sudoers de forma segura: visudo y /etc/sudoers.d

No abras nunca /etc/sudoers directamente con un editor. Un error de sintaxis deja sudo inservible para todos los usuarios, y si el acceso root ya está cerrado, solo te queda la consola. visudo bloquea el archivo frente a modificaciones simultáneas y comprueba la sintaxis antes de guardar. Si encuentra un error, pregunta:

>>> /etc/sudoers: syntax error near line 22 <<<
What now?
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

La respuesta correcta es e; la Q mayúscula guarda el archivo defectuoso. Qué editor arranca visudo lo decide en Debian y Ubuntu el sistema de alternativas: de forma permanente con update-alternatives --config editor y solo por una vez con EDITOR=nano visudo.

Para tus propias reglas, ni siquiera toques /etc/sudoers. Al final del archivo hay una línea que incluye un directorio entero, según la antigüedad del sistema como @includedir /etc/sudoers.d o como #includedir /etc/sudoers.d. La almohadilla parece un signo de comentario, pero no lo es. Ese archivo también lo creas con visudo:

visudo -f /etc/sudoers.d/10-kernel

Las dos reglas con las que fallan los archivos de ese directorio

El nombre del archivo no puede contener un punto ni terminar en el carácter ~. sudo se salta esos archivos en silencio, para que los archivos de backup no acaben concediendo permisos sin querer. Por eso 10-kernel.conf no se lee nunca, y además sin ningún aviso. Lo correcto es 10-kernel.

El archivo tiene que pertenecer a root y no puede tener permiso de escritura para el grupo ni para los demás: lo que se espera es el modo 0440.

chown root:root /etc/sudoers.d/10-kernel
chmod 0440 /etc/sudoers.d/10-kernel
visudo -c

visudo -c comprueba todos los archivos incluidos y saca una línea por cada uno:

/etc/sudoers: parsed OK
/etc/sudoers.d/10-kernel: parsed OK

Esa es a la vez la mejor prueba para la primera regla: si tu archivo no aparece ahí, no se está leyendo, y en ese caso la causa casi siempre es un punto en el nombre. Si los permisos son incorrectos, visudo avisa en cambio con /etc/sudoers.d/10-kernel: bad permissions, should be mode 0440.

NOPASSWD: lo que cuesta de verdad

Tarde o temprano todo el mundo se topa con esta línea:

kernel ALL=(ALL) NOPASSWD: ALL

Es más peligrosa de lo que parece. La petición de contraseña es la última barrera entre "alguien tiene una shell como kernel" y "alguien es root". Quien llegue a la cuenta a través de una aplicación web vulnerable, de una clave privada copiada o de una sesión desatendida, con esta línea ya es root sin dar ningún paso más. Con NOPASSWD: ALL, la ganancia de seguridad frente a entrar directamente como root se reduce, por tanto, a un nombre de usuario que el atacante no conoce.

NOPASSWD está justificado allí donde no hay nadie que pueda teclear: ejecuciones de Ansible, scripts de backup, pipelines de despliegue. Pero entonces bien acotado, y no para la persona que está delante del terminal:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Tres trampas con reglas de este tipo:

• Las rutas absolutas son obligatorias. Un nombre de programa sin ruta no coincide con nada.
• Si no indicas argumentos, están permitidos todos. deploy ALL=(root) NOPASSWD: /usr/bin/systemctl autoriza cualquier llamada a systemctl. Solo cuando escribes también los argumentos, la línea de comandos tiene que coincidir exactamente. Si no quieres permitir ningún argumento, añade un argumento vacío, por ejemplo /usr/bin/id "".
• Los comodines casi nunca son tan estrictos como parecen. /usr/bin/* permite cualquier programa de ese directorio y equivale en la práctica a acceso root completo.

La pregunta más importante ante cualquier regla restringida: ¿puede el comando permitido arrancar otro programa o abrir una shell? Los editores, los gestores de paquetes, las herramientas de archivado y los intérpretes pueden hacerlo, y una regla que permite un editor por sudo permite en la práctica cualquier cosa.

El compromiso más razonable está en el tiempo que sudo recuerda la contraseña: por defecto la conserva 15 minutos, y por separado para cada terminal. Eso se puede ajustar en /etc/sudoers.d/:

Defaults:kernel timestamp_timeout=5

sudo -k descarta esa marca de tiempo de inmediato y sudo -v la renueva sin ejecutar ningún comando.

Llevar la clave pública al usuario nuevo

Mientras siga activo el inicio de sesión por contraseña en SSH, lo más cómodo desde tu equipo de trabajo es ssh-copy-id kernel@203.0.113.10. Si ya lo has desactivado, eso falla con Permission denied (publickey). Entonces el camino pasa por la sesión root que sigue abierta.

Ahí lo primero que se le ocurre a cualquiera es cp -r /root/.ssh /home/kernel/.ssh, y está mal: después los archivos pertenecen a root, el servidor SSH los rechaza, y el comando se lleva de paso una posible clave privada de root, que no pinta nada en una segunda cuenta. Copia en su lugar únicamente las claves públicas:

install -d -m 700 -o kernel -g kernel /home/kernel/.ssh
install -m 600 -o kernel -g kernel /root/.ssh/authorized_keys /home/kernel/.ssh/authorized_keys

install establece permisos y propietario de una sola vez, así que no queda ningún chown olvidado. Si /root/.ssh/authorized_keys no existe, crea el archivo de destino vacío y añade la clave con un editor:

install -m 600 -o kernel -g kernel /dev/null /home/kernel/.ssh/authorized_keys

Comprobación:

ls -ld /home/kernel /home/kernel/.ssh
ls -l /home/kernel/.ssh/authorized_keys
ssh-keygen -l -f /home/kernel/.ssh/authorized_keys

La última línea saca la huella digital de cada clave almacenada. Compárala con la de ssh-keygen -l -f ~/.ssh/id_ed25519.pub en tu equipo de trabajo. Así sabes ya antes del primer intento de conexión que ha llegado la clave correcta.

Un detalle que puede costar horas: con StrictModes yes, el servidor SSH no comprueba solo .ssh y authorized_keys, sino también el directorio personal. Si tiene permiso de escritura para el grupo o para los demás, rechaza el acceso por clave y el cliente se limita a informar de Permission denied (publickey). Qué permisos asigna tu sistema está en /etc/adduser.conf, bajo DIR_MODE. Todo lo relativo al acceso por clave lo tienes en Asegurar SSH y configurar el acceso por clave.

La prueba antes de cerrar el acceso root

Cuatro comprobaciones, y solo cuando todas salgan bien tocas la configuración de SSH. La sesión root antigua se queda abierta.

Primera: una sesión SSH nueva con el usuario nuevo, en una ventana recién abierta, no dentro de la conexión que ya tienes.

ssh kernel@203.0.113.10

Lo esperado es una shell sin petición de contraseña. Si te pide una contraseña, la clave no ha funcionado; ssh -v muestra qué claves ofrece el cliente en realidad. Si ya se atasca el establecimiento de la conexión, te ayuda Conectarse a un servidor por SSH.

Segunda: sudo dentro de esa misma sesión nueva.

id
sudo -v
sudo id

id tiene que incluir el grupo sudo, y sudo id tiene que empezar por uid=0(root). Un sudo -l -U kernel desde la sesión root no sustituye a esta prueba: muestra lo que sudo permitiría, no si funciona el inicio de sesión del usuario.

Tercera: la consola. Entra por la consola VNC del área de cliente como kernel con nombre de usuario y contraseña, y ejecuta ahí sudo -i. Esta prueba es la más importante de las cuatro, porque la consola es la vía de rescate y solo entiende contraseñas.

Cuarta: el estado de las contraseñas.

passwd -S root
passwd -S kernel

En al menos una de las dos cuentas tiene que aparecer una P en la segunda columna. Dos cuentas bloqueadas más una configuración SSH defectuosa dan como resultado un sistema al que ya solo se llega con un sistema de rescate.

Cerrar el acceso root, pero bien

Hay tres medidas que se suelen meter en el mismo saco, aunque sus consecuencias son muy distintas.

Para la mayoría de los servidores, prohibit-password es la opción correcta: root sigue estando accesible por clave como último recurso y, aun así, adivinar contraseñas no tiene ninguna posibilidad. Ese ajuste va en un archivo propio dentro de /etc/ssh/sshd_config.d/, y antes de cada reinicio del servicio va la comprobación de sintaxis:

sshd -t && systemctl restart ssh
sshd -T | grep -i permitrootlogin

passwd -l root es la variante más dura y solo es defendible si has hecho la tercera prueba de arriba. El comando bloquea únicamente el inicio de sesión por contraseña: una clave SSH almacenada sigue funcionando, y sudo -i también.

Lo que no conviene hacer: quitarle a root la shell de inicio de sesión, por ejemplo con usermod -s /usr/sbin/nologin root. Eso no solo bloquea el inicio de sesión, sino también sudo -i y la shell de emergencia durante el arranque.

Errores frecuentes y soluciones

kernel is not in the sudoers file.: el usuario no pertenece a ningún grupo para el que exista una regla, o la sesión es más antigua que el cambio de grupo. Comprueba id -nG kernel como root, luego getent group sudo y después vuelve a iniciar sesión. Las versiones antiguas todavía añaden una frase sobre un incidente notificado.

sudo: 3 incorrect password attempts aunque hayas tecleado bien: la cuenta no tiene ninguna contraseña, normalmente porque se creó con --disabled-password. En ese caso passwd -S kernel muestra L o NP, y passwd kernel lo resuelve. Además, sudo pregunta por la contraseña del usuario que lo llama, no por la de root.

sudo: no tty present and no askpass program specified: no hay ningún terminal en el que sudo pueda preguntar. Es típico con ssh server 'sudo comando' y en los cronjobs. Con SSH ayuda ssh -t; en un cronjob, la entrada va en la crontab de root.

sudo: /etc/sudoers.d/10-kernel is mode 0644, should be 0440: permisos incorrectos en el archivo de reglas. chmod 0440 lo arregla; hasta entonces la regla no surte efecto.

/etc/sudoers.d/10-kernel: bad permissions, should be mode 0440: la misma causa, avisada por visudo -c. Usa ese comando después de cada cambio.

El archivo de reglas no aparece en absoluto en la salida de visudo -c: el nombre contiene un punto o termina en el carácter ~. Renombra 10-kernel.conf como 10-kernel.

usermod: group 'sudo' does not exist: estás trabajando en un sistema de la familia RHEL. Ahí el grupo de administración se llama wheel, algo que confirma getent group wheel.

Permission denied (publickey) con el usuario nuevo, mientras root sigue pudiendo entrar: casi siempre son los permisos. /home/kernel/.ssh tiene que ser 700, authorized_keys 600, los dos tienen que pertenecer al usuario, y el directorio personal no puede tener permiso de escritura para el grupo ni para los demás. La causa está en el journal:

journalctl -t sshd -n 50 --no-pager

Lo que buscas es una línea que empiece por Authentication refused: bad ownership or modes for directory y que nombre el directorio afectado.

sudo: unable to resolve host srv01: Name or service not known: falta el nombre de host en /etc/hosts. sudo funciona igualmente, pero con un retraso perceptible. La entrada que hace falta está en la checklist para servidores root.

Y si la cuenta tiene que volver a desaparecer: gpasswd -d kernel sudo quita solo los permisos, mientras que deluser --remove-home kernel o bien userdel -r kernel la elimina junto con su directorio personal.

Diferencias entre distribuciones de un vistazo

Resumen

1. Deja claro el camino de vuelta: mantén abierta una segunda sesión root, prueba una vez la consola VNC del área de cliente y ten a mano la contraseña de root.
2. apt-get install -y sudo si command -v sudo no devuelve nada.
3. adduser --disabled-password --gecos "" kernel y después passwd kernel, para que la consola siga siendo utilizable.
4. usermod -aG sudo kernel, y en los sistemas de la familia RHEL, wheel. La -a es obligatoria.
5. Copia la clave pública con install: directorio 700, archivo 600 y el usuario nuevo como propietario.
6. Tus propias reglas, solo con visudo -f en /etc/sudoers.d/, nombre de archivo sin punto, modo 0440 y después visudo -c.
7. Comprueba: sudo -l -U kernel, una sesión SSH nueva, sudo id y el inicio de sesión en la consola con contraseña.
8. No toques PermitRootLogin hasta haber pasado todo lo anterior.

Un usuario con permisos de sudo te quita de encima el destrozo total accidental y el nombre de usuario más conocido. Contra los puertos abiertos ayuda el firewall UFW; contra los ataques que saturan la conectividad, solo el filtrado en la red que hay por delante, en el caso de KernelHost en el centro de datos maincubes de Fráncfort del Meno. En el propio servidor, tu tarea sigue siendo la más pequeña y a la vez la más eficaz: que exactamente una cuenta tenga exactamente los permisos que necesita.