Crear el usuario
En Ubuntu y Debian, adduser pide una contraseña y algunos datos opcionales, que puedes saltar con Enter:
sudo adduser deploy
sudo usermod -aG sudo deployLa opción -a importa: sin ella, -G reemplaza los demás grupos del usuario. Un Debian mínimo puede no tener sudo, así que ejecuta antes apt install sudo como root.
En RHEL, Rocky, AlmaLinux y Fedora el grupo de administración es wheel:
sudo useradd -m -G wheel deploy
sudo passwd deployComprueba el resultado:
id deploy
sudo -l -U deployInstalar la clave SSH
Ejecuta esto en el servidor, con la clave pública del usuario en lugar del ejemplo. Fija propietario y modos en un solo paso:
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' | sudo install -m 600 -o deploy -g deploy /dev/stdin /home/deploy/.ssh/authorized_keysEsto escribe un archivo nuevo y reemplaza el que hubiera, así que úsalo solo con una cuenta nueva. Si la cuenta tiene contraseña y el acceso por contraseña está activado, puedes hacerlo desde tu propio equipo, lo que añade la clave:
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@serverEn sistemas con SELinux en modo enforcing, corrige también las etiquetas:
sudo restorecon -R /home/deploy/.sshLos permisos que importan
| Ruta | Propietario | Modo |
|---|---|---|
/home/deploy | deploy | sin escritura para otros, por ejemplo 750 |
/home/deploy/.ssh | deploy | 700 |
/home/deploy/.ssh/authorized_keys | deploy | 600 |
El error clásico es crear estos archivos como root y olvidar el propietario. En nuestra prueba, un archivo de root con modo 600 dio este resultado, porque el usuario no puede leerlo:
deploy@server: Permission denied (publickey,password).Comprueba con esto, y mira Permission denied (publickey) si los propietarios y modos son correctos pero sigue fallando:
sudo stat -c '%a %U %n' /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keysDebian y Ubuntu son más permisivos con las carpetas con escritura de grupo cuando el grupo es el privado del usuario: nuestro acceso funcionó con .ssh en 775. No cuentes con ello, porque otros sistemas lo rechazan. Ciñete a la tabla.
Pruébalo antes de cerrar tu sesión
Abre una terminal nueva y deja la anterior abierta:
ssh deploy@server
sudo whoamiEl segundo comando debe imprimir root tras pedir la contraseña de deploy. Solo entonces es seguro desactivar el acceso de root o el acceso por contraseña.
Un usuario con clave y sin contraseña
Para una cuenta creada desde un script:
sudo adduser --disabled-password --comment "" deployEn versiones más antiguas, como Ubuntu 22.04, la opción es --gecos "". El acceso con clave siguió funcionando en nuestra prueba con Ubuntu 24.04, pero sudo no puede pedir una contraseña que no existe:
sudo: a password is requiredPon una contraseña, o permite sudo sin ella para este usuario. Crea siempre ese archivo con visudo, que rechaza un archivo roto:
sudo visudo -f /etc/sudoers.d/90-deploycon esta línea dentro:
deploy ALL=(ALL) NOPASSWD:ALLTen claro el coste: quien consiga esta clave, o una shell como este usuario, tiene root al instante. A veces la automatización lo necesita, y una persona que entra a mano rara vez. Mira cómo usar sudo por SSH de forma segura.
Preguntas
¿Cómo doy sudo a un usuario que ya existe?
Ejecuta sudo usermod -aG sudo usuario en Debian y Ubuntu, o sudo usermod -aG wheel usuario en RHEL y Fedora. El usuario lo tiene en su siguiente inicio de sesión.
¿Por qué sudo me pide contraseña si entro con clave?
Son cosas distintas. La clave demuestra a SSH quién eres. sudo pide la contraseña de la propia cuenta, salvo que el archivo sudoers diga otra cosa.
¿Tengo que cerrar sesión después de añadir el grupo?
Sí. La pertenencia a grupos se lee al iniciar sesión, así que una sesión abierta antes de usermod no la tiene.
Fuentes
- sshd(8), AUTHORIZED_KEYS y permisos de archivos, manual de OpenBSD
- sshd_config(5), StrictModes, manual de OpenBSD