Un usuario con sudo en lugar de trabajar como root

Qué cambia cuando dejás de entrar como root

root no pregunta. Un rm con la ruta equivocada, un chown recursivo un directorio más arriba de lo que querías, un editor que guarda donde no era: todo eso se ejecuta sin confirmación y no hay papelera. Con una cuenta normal, lo destructivo necesita que escribas sudo adelante, y ese medio segundo es justo el que te falta cuando te equivocás.

Después está el registro. Si tres personas entran como root, el servidor anota que root hizo algo y ahí se termina la información. Con una cuenta por persona, cada comando con sudo queda anotado con el nombre de quien lo corrió, y lo que se rompió a las tres de la mañana se reconstruye en lugar de adivinarse.

Y cambia cómo se saca a alguien: si el equipo compartía la contraseña de root, que se vaya una persona obliga a cambiarla y avisarle a todos. Con cuentas propias, se borra una cuenta y nadie más se entera.

El orden completo, de principio a fin

1. Creás la cuenta con adduser.
2. La agregás al grupo sudo.
3. Le copiás la clave SSH, con el dueño y los permisos correctos.
4. Abrís una segunda terminal y comprobás que la cuenta entra por clave.
5. En esa misma sesión comprobás que sudo funciona.
6. Recién ahí ponés PermitRootLogin no y reiniciás el servicio.
7. Verificás que root ya no entra y que vos sí.

Crear la cuenta

1. Entrá al servidor con la cuenta que ya tenga privilegios y escribí sudo adduser juan.
2. El comando te pide una contraseña y unos datos opcionales que podés saltear con Enter. Lo importante es lo que hace sin avisar: crea /home/juan, le asigna un intérprete de comandos y arma el grupo propio del usuario.
3. No uses useradd para esto. Es el comando de más abajo y no arma nada de eso: la cuenta queda sin home y sin un intérprete usable, y después la clave SSH no funciona porque no hay dónde poner el archivo authorized_keys.
4. Dale permisos de administración con sudo adduser juan sudo. El grupo se llama sudo, y pertenecer a él es lo que habilita el comando.
5. Verificá con id juan: entre los grupos tiene que aparecer sudo.
6. Si juan ya estaba conectado en otra terminal, tiene que salir y volver a entrar. Los grupos se leen cuando se abre la sesión, así que en la sesión vieja sudo va a seguir diciendo que no está autorizado.

Pasarle la clave SSH a la cuenta nueva

1. Lo más simple, desde tu computadora: ssh-copy-id juan@203.0.113.24, con la contraseña que le acabás de poner. Esto requiere que el servidor todavía acepte contraseñas.
2. Si ya las apagaste, hacelo desde la sesión que tenés abierta. Primero la carpeta, ya con dueño y permisos: sudo install -d -m 700 -o juan -g juan /home/juan/.ssh.
3. Después el archivo, copiando el que ya usa root: sudo install -m 600 -o juan -g juan /root/.ssh/authorized_keys /home/juan/.ssh/authorized_keys.
4. Si preferís hacerlo con mkdir y cp, acordate del dueño: sudo chown -R juan:juan /home/juan/.ssh. Es el paso que más se olvida y el que deja la clave sin funcionar.
5. Copiar la clave de root solo tiene sentido si esa clave es tuya. Si la cuenta es para otra persona, que te mande su clave pública y pegás esa, una por línea.

Probar las dos cosas antes de seguir

1. Dejá abierta la sesión actual y abrí una segunda terminal.
2. Entrá con la cuenta nueva: ssh juan@203.0.113.24. Tiene que entrar sin pedir contraseña del servidor.
3. Escribí id para confirmar que sos juan y que el grupo sudo está.
4. Probá sudo de verdad, no en el aire: sudo systemctl status ssh. Te va a pedir la contraseña de juan, no la de root, y después tiene que mostrar el estado del servicio.
5. Si aparece el mensaje de que juan no figura en el archivo de sudoers, no sigas: falta el grupo, o falta cerrar y volver a abrir la sesión.

Cerrar el acceso directo de root

1. Copiá el archivo: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original.
2. Editalo con sudo nano /etc/ssh/sshd_config y poné PermitRootLogin no.
3. Si querés un paso intermedio, prohibit-password deja entrar a root solo con clave y nunca con contraseña. Es el valor que OpenSSH trae de fábrica, así que es lo que ya tenías si nadie lo tocó.
4. Revisá también /etc/ssh/sshd_config.d/: lo que esté ahí se lee antes y puede contradecir lo que escribiste.
5. Validá con sudo sshd -t y aplicá con sudo systemctl restart ssh.service.
6. Comprobá desde afuera: ssh root@203.0.113.24 tiene que rebotar, y ssh juan@203.0.113.24 tiene que entrar. Las dos cosas, en ese orden.

Qué se rompe si lo hacés en el orden equivocado

En Ubuntu la contraseña de root viene bloqueada de fábrica, así que si perdés sudo no tenés un su al que recurrir: la salida es la consola del panel.

sudo con contraseña o sin contraseña

Por defecto sudo pide la contraseña del propio usuario, no la de root, y no la vuelve a pedir durante unos minutos en la misma terminal. Es un equilibrio razonable: molesta poco y frena el comando destructivo que escribiste sin pensar.

Las imágenes de nube suelen traer su usuario inicial con sudo sin contraseña, porque esa cuenta entra solo con clave y directamente no tiene contraseña que tipear. En un servidor de una sola persona es defendible. En uno donde trabajan varios, deja de serlo: cualquiera que se siente frente a una terminal abierta es root sin fricción.

Si vas a tocar la configuración de sudo, no abras /etc/sudoers con nano. Usá sudo visudo, o creá un archivo propio con sudo visudo -f /etc/sudoers.d/juan. visudo revisa la sintaxis antes de guardar; un editor común te deja guardar un archivo roto, y un sudoers roto deja a todo el mundo sin sudo al mismo tiempo.