Cambiar la contraseña de root en Ubuntu VPS

Cómo cambiar la contraseña de root de su VPS en Ubuntu

Para cambiar la contraseña de root de su VPS (servidor privado virtual) en Ubuntu, abra una sesión SSH (Secure Shell) con un usuario que pueda ejecutar sudo y, después, ejecute sudo passwd root. El sistema solicita la nueva contraseña dos veces y no solicita la anterior, porque sudo ya ha verificado su identidad. Para cambiar su propia contraseña de inicio de sesión, ejecute passwd sin argumentos. El sistema solicita primero la contraseña actual.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Esa es toda la operación. Todo lo que sigue explica los problemas habituales: comprobar que la nueva contraseña funciona antes de perder la sesión que permitiría corregirla, establecer contraseñas desde un script, hacer que una contraseña caduque de forma intencionada y recuperar el acceso cuando la contraseña ya se ha perdido.

Abra una segunda sesión antes de cambiar una contraseña

Abra ahora una segunda sesión SSH y déjela conectada. Casi todos los fallos de esta guía se solucionan en dos minutos mientras haya un shell autenticado activo. Si se cierra el último shell, normalmente tendrá que acceder mediante la consola.

Un shell que ya está abierto sigue funcionando después de cambiar, bloquear o hacer caducar la cuenta a la que pertenece. SSH comprueba las credenciales al iniciar sesión y no vuelve a comprobarlas después. La excepción es sudo. Este vuelve a comprobar la contraseña mediante PAM (módulos de autenticación conectables) cuando caduca su marca de tiempo, 15 minutos después del último aviso de forma predeterminada. Por tanto, la nueva contraseña se prueba realmente la próxima vez que sudo la solicite, no al iniciar sesión.

Pruebe la nueva contraseña en la segunda sesión mientras mantiene abierta la primera.

Cambia tu propia contraseña con passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully es el único resultado que indica que se reemplazó el hash de /etc/shadow. Cualquier otro resultado deja la contraseña anterior sin cambios.

Aquí se producen dos fallos. passwd: Authentication token manipulation error, seguido de passwd: password unchanged, indica que la contraseña actual introducida era incorrecta o que no se puede escribir en el sistema de archivos que contiene /etc/shadow, que es el estado normal en el modo de recuperación. You must choose a longer password. procede de pam_unix en /etc/pam.d/common-password, que aplica comprobaciones de longitud y similitud a los usuarios normales.

En la mayoría de las imágenes de VPS, la cuenta predeterminada (ubuntu o el nombre que proporcione el proveedor) no tiene contraseña, sino únicamente una clave SSH. passwd no tiene una contraseña actual que comprobar, por lo que no puede superar el primer aviso. Use sudo passwd $USER en su lugar. Funciona porque el archivo adicional de sudoers de la imagen permite que esa cuenta ejecute sudo sin contraseña.

Cambiar la contraseña de otro usuario con sudo passwd

sudo passwd deploy

root no debe introducir la contraseña anterior, y pam_unix omite las comprobaciones de complejidad que aplica a los usuarios normales. Por tanto, root puede establecer una contraseña que el usuario no habría podido establecer por sí mismo.

Bloquear la contraseña es una acción independiente. sudo passwd -l deploy antepone un ! al hash almacenado, por lo que ninguna contraseña coincide con él. sudo passwd -u deploy lo elimina. Consulte el estado con sudo passwd -S deploy.

Bloquear la contraseña no impide que el usuario inicie sesión. Cualquier clave de su archivo ~/.ssh/authorized_keys sigue funcionando, porque la autenticación con clave pública nunca lee /etc/shadow. Para detener completamente una cuenta, haga que la propia cuenta caduque:

sudo usermod --expiredate 1 deploy

Esto establece la caducidad de la cuenta en una fecha de 1970, por lo que sshd rechaza el inicio de sesión con cualquier credencial. Deshaga el cambio con sudo usermod --expiredate '' deploy.

Evite passwd -d. Establece una contraseña vacía en lugar de bloquearla, y en una versión antigua que todavía incluya nullok en la pila PAM, una contraseña vacía puede utilizarla cualquiera.

¿Necesita root una contraseña en un VPS?

Ubuntu se distribuye con root bloqueado. /etc/shadow contiene ! en lugar de un hash, y sudo passwd -S root muestra una línea que comienza por root L. Nadie puede iniciar sesión como root con una contraseña hasta que se establezca una, por eso la imagen proporciona un usuario con permisos de sudo. Conviene mantener el patrón de trabajar mediante cuentas de usuario con privilegios mínimos en un VPS en lugar de hacerlo como root.

Establecer una contraseña para root proporciona una ventaja concreta: una vía de acceso mediante la consola del proveedor. Esa consola se conecta a la máquina virtual por debajo de la pila de red, por lo que sigue funcionando cuando sshd está mal configurado o una regla del firewall es incorrecta. También tiene un coste. El shell de root del menú de recuperación de GRUB solicita la contraseña de root cuando esta existe. Por tanto, la herramienta que usaría para restablecer una contraseña olvidada queda protegida por esa misma contraseña.

Establecer una contraseña para root no permite que root inicie sesión mediante SSH. Ubuntu se distribuye con PermitRootLogin prohibit-password, lo que significa que sólo se permiten claves. Compruebe qué utiliza realmente su servidor:

sudo sshd -T | grep -i permitrootlogin

sshd -T muestra la configuración efectiva después de resolver cada línea Include, por lo que es la única respuesta fiable cuando /etc/ssh/sshd_config.d/ contiene archivos drop-in.

Establecer una contraseña desde un script con chpasswd

passwd lee desde el terminal y no puede ejecutarse desde un script. chpasswd lee pares user:password desde la entrada estándar, uno por línea.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Esto funciona, pero deja una contraseña en texto plano en el historial del shell y en los registros de CI (integración continua). Genere primero un hash:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 solicita la contraseña dos veces sin mostrarla y después imprime un hash crypt SHA-512 que empieza por $6$. -e indica a chpasswd que el segundo campo ya contiene un hash, por lo que se copia tal cual en /etc/shadow. El hash se puede guardar de forma segura en un repositorio o en una variable de CI, y la contraseña en texto plano nunca sale del equipo donde se introdujo.

Ubuntu 24.04 genera hashes yescrypt para las contraseñas nuevas ($y$) cuando passwd las establece, mientras que openssl passwd -6 genera SHA-512. Ambos formatos se verifican durante el inicio de sesión porque libxcrypt puede leerlos. Se pueden mezclar sin problema, y openssl passwd -6 se comporta igual en todas las versiones LTS de Ubuntu, a diferencia de chpasswd -c YESCRYPT: el paquete shadow antiguo de 20.04 no reconoce ese nombre de método. Estos hashes también se conservan al actualizar de versión, por lo que actualizar un servidor 24.04 a 26.04 no obliga a restablecer la contraseña de nadie.

¿Cómo se comprueba que la contraseña realmente cambió?

Empiece por los metadatos y después confírmelo iniciando sesión.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

El segundo campo es el estado: P indica que la contraseña se puede usar, L que está bloqueada y NP que no hay ninguna contraseña. La fecha indica cuándo se cambió la contraseña por última vez, por lo que debería ser la de hoy. Los números siguientes son los campos de caducidad que se explican más abajo.

La prueba en vivo más segura es el propio sudo. sudo -k descarta la marca de tiempo almacenada en caché y sudo -v fuerza una nueva solicitud. Si allí se acepta la contraseña nueva, PAM la ha aceptado y la sesión actual no ha cambiado.

sudo -k && sudo -v

Para probar otra cuenta, ejecute su - deploy desde un shell sin privilegios. No ejecute sudo su - deploy, porque a root nunca se le solicita una contraseña y la prueba no demostraría nada. Una contraseña incorrecta muestra su: Authentication failure.

La prueba real consiste en iniciar sesión mediante SSH desde el portátil, con la sesión de trabajo todavía abierta:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). aquí significa que el servidor nunca ofreció autenticación mediante contraseña, por lo que ningún cambio de contraseña permitirá iniciar sesión. Permission denied, please try again. significa que sí la ofreció, pero rechazó lo que escribió.

Forzar el cambio de contraseña en el siguiente inicio de sesión con chage

sudo chage -d 0 deploy

-d 0 establece la fecha del último cambio en la época Unix, por lo que PAM considera que la contraseña ha caducado. En el siguiente inicio de sesión interactivo, se solicita la contraseña actual y después una nueva antes de proporcionar un shell. sudo passwd -e deploy hace exactamente lo mismo.

Úselo sólo con cuentas que inicien sesión de forma interactiva mediante contraseña. Una contraseña caducada también afecta a los inicios de sesión mediante claves, porque sshd ejecuta la fase de cuenta de PAM incluso cuando una clave ha realizado la autenticación. Un ssh deploy@203.0.113.10 'systemctl restart app' programado falla con este mensaje y se detiene:

Password change required but no TTY available.

No se ejecuta nada después de esa línea y el trabajo sólo informa de un código de salida distinto de cero.

Qué significan los campos de caducidad de la contraseña

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Esos números corresponden a los campos 4 a 8 de la línea de ese usuario en /etc/shadow. Los días mínimos (chage -m) indican cuánto tiempo debe esperar el usuario antes de volver a cambiar la contraseña. Esto impide que vuelva directamente a la contraseña anterior después de un cambio forzado. Los días máximos (chage -M) indican cuánto tiempo sigue siendo válida la contraseña. Los días de aviso (chage -W) indican cuándo empiezan a mostrarse advertencias al iniciar sesión. Los días de inactividad (chage -I) son el periodo de gracia posterior a la caducidad. Cuando termina, la contraseña deja de aceptarse. La caducidad de la cuenta (chage -E) es una fecha límite independiente de la contraseña.

sudo chage -M 90 -W 14 deploy

Establézcalo sólo cuando una política lo exija. NIST (el National Institute of Standards and Technology de Estados Unidos) desaconseja desde 2017 la caducidad periódica de las contraseñas. Esta práctica lleva a los usuarios a crear variaciones predecibles de una misma contraseña. NIST recomienda forzar el cambio cuando existan indicios de que la contraseña se ha visto comprometida. Una contraseña larga y única almacenada en un gestor de contraseñas, junto con SSH basado en claves, ofrece más seguridad que un ciclo de 90 días.

Qué hacer cuando ha perdido la contraseña de root

Si alguna cuenta del servidor puede ejecutar sudo, no hay nada que recuperar: sudo passwd root establece una nueva contraseña. El caso difícil es no disponer de ningún inicio de sesión operativo.

Todo lo siguiente requiere la consola del proveedor, que en la mayoría de los paneles aparece como consola VNC (virtual network computing) o consola serie. Esta consola se conecta a la máquina virtual por debajo de la pila de red, por lo que la configuración de sshd y las reglas del firewall no le afectan.

1. Reinicie el servidor desde el panel y observe la consola.
2. Abra el menú de GRUB. Las imágenes en la nube suelen establecer GRUB_TIMEOUT=0, así que mantenga pulsada Shift durante un arranque BIOS o pulse Esc varias veces durante un arranque UEFI, en cuanto comience el reinicio.
3. Elija Advanced options for Ubuntu, después la entrada que termina en (recovery mode) y, a continuación, root en el menú de recuperación.
4. Ejecute primero mount -o remount,rw /. La recuperación monta el sistema de archivos raíz en modo de solo lectura, por lo que, sin este paso, passwd falla con passwd: Authentication token manipulation error porque no puede escribir en /etc/shadow.
5. Ejecute passwd ubuntu para la cuenta que necesite y reinicie desde el panel.

Si root ya tiene una contraseña y la que ha perdido es esa, el shell de recuperación se la solicitará y esta vía queda cerrada. En su lugar, arranque la imagen de rescate del proveedor, monte el disco real y cambie la contraseña dentro de ese sistema.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Consulte la distribución de particiones con lsblk en lugar de copiar /dev/vda1 de esta página. La partición raíz es la de mayor tamaño. En una imagen UEFI se encuentra junto a una partición EFI pequeña que no contiene ningún directorio /etc.

Qué hacer cuando SSH deja de aceptar la contraseña

Trabaje desde la sesión que todavía tiene abierta. Si no queda ninguna sesión, use la consola.

Permission denied, please try again. significa que el servidor ofreció autenticación mediante contraseña y rechazó lo que envió. Las causas habituales son tener activado el bloqueo de mayúsculas o usar una distribución de teclado de consola distinta de la que empleó al establecer la contraseña.

Permission denied (publickey). significa que el servidor nunca ofreció autenticación mediante contraseña. PasswordAuthentication no está definido en algún lugar y, en Ubuntu 22.04 y posteriores, normalmente se encuentra en un archivo de configuración adicional bajo /etc/ssh/sshd_config.d/ que sobrescribe el archivo principal. Lea los valores efectivos:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes junto con PasswordAuthentication no todavía permite usar una contraseña, porque el método keyboard-interactive ejecuta la misma pila de PAM. Desactivar uno y dejar el otro habilitado hace que un servidor que parece aceptar sólo claves siga aceptando contraseñas introducidas manualmente.

Esa misma línea también aparece cuando se rechaza un inicio de sesión con clave. Por tanto, si estaba ofreciendo una clave y no una contraseña, la configuración de contraseñas del servidor es sólo uno de los cinco problemas que provocan Permission denied (publickey), y la salida de ssh -v indica cuál es el que tiene.

Too many authentication failures en un mensaje de desconexión significa que el cliente ofreció varias claves antes de llegar a la contraseña y el servidor alcanzó MaxAuthTries, cuyo valor predeterminado es 6. Fuerce un único método:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused en un puerto que funcionaba hace un minuto normalmente significa que fail2ban supervisaba SSH y bloqueó su dirección tras varios intentos fallidos. Su regla de bloqueo predeterminada rechaza el paquete en lugar de descartarlo. Por eso el rechazo llega rápidamente en vez de producir un tiempo de espera. Desde la consola, sudo fail2ban-client status sshd muestra las direcciones bloqueadas y sudo fail2ban-client set sshd unbanip 203.0.113.10 elimina la suya.

Las contraseñas son un paso intermedio; las claves son el estado final

Una contraseña que funciona mediante SSH es una contraseña que cualquier escáner de Internet puede intentar adivinar. Cambie a la autenticación basada en claves para que los intentos de adivinación dejen de ser relevantes. Genere un par de claves, instale la clave pública y confirme desde un segundo terminal que la clave permite iniciar sesión antes de cambiar cualquier otra cosa. Conceptos básicos de la gestión de claves SSH explica la generación, authorized_keys y las frases de contraseña.

Después, desactive la autenticación mediante contraseña y confírmelo con sudo sshd -T en lugar de confiar en el archivo que editó. Refuerzo de la seguridad de SSH en un VPS explica el resto de los ajustes de sshd que conviene cambiar, y Los primeros diez minutos en un VPS nuevo los ordena según el momento en que deben aplicarse en un servidor recién instalado.

Conserve una contraseña después de eso. Un servidor que sólo admite claves y tiene una configuración de sshd incorrecta sólo es accesible mediante la consola del proveedor, y esa consola solicita un nombre de usuario y una contraseña. Una cuenta cuya contraseña segura esté guardada es lo que diferencia una reparación de cinco minutos de una reinstalación.

FAQ

¿Cómo cambio la contraseña de root en mi VPS si no conozco la anterior?

Inicie sesión con un usuario que pueda ejecutar sudo y ejecute sudo passwd root. Establece una contraseña nueva sin solicitar la anterior, porque sudo ya le ha autenticado. Si ninguna cuenta del servidor puede ejecutar sudo, abra la consola del proveedor, reinicie el sistema en el menú de recuperación de GRUB, seleccione la entrada de shell root, ejecute mount -o remount,rw / y, después, passwd. Si root ya tiene una contraseña y esa es la que ha perdido, el shell de recuperación la solicita. En ese caso, la alternativa es usar la imagen de rescate del proveedor, montar el disco y ejecutar chroot.

¿Por qué passwd muestra "Authentication token manipulation error"?

Ese mensaje tiene dos causas. La más habitual es introducir una respuesta incorrecta en el indicador Current password:; la línea passwd: password unchanged que aparece debajo confirma que no se escribió nada. La otra causa es un sistema de archivos que no permite escrituras. Esto ocurre en el modo de recuperación porque allí / está montado como solo lectura. Ejecute mount -o remount,rw / y vuelva a intentarlo.

¿Cambiar mi contraseña de Linux también cambia mi contraseña de sudo?

Sí. sudo no tiene una contraseña propia. Le autentica mediante PAM contra la misma entrada de /etc/shadow que utilizan SSH y su, por lo que cada cuenta tiene una sola contraseña. Por eso el primer indicador de sudo después del cambio es la prueba real. Ejecute sudo -k && sudo -v para forzar ese indicador mientras todavía tenga una sesión operativa.

¿Cambiar mi contraseña romperá mis claves SSH o mis sesiones abiertas?

No. La autenticación mediante clave pública nunca lee /etc/shadow, por lo que las claves siguen funcionando después de cambiar la contraseña, después de passwd -l y después de chage -d 0. Las sesiones que ya están abiertas permanecen abiertas porque SSH comprueba las credenciales únicamente al iniciar sesión. El único elemento que cambia dentro de una sesión activa es sudo, que solicita la contraseña nueva cuando caduca su marca de tiempo de 15 minutos.

¿Cómo obligo a un usuario a cambiar su contraseña en el siguiente inicio de sesión?

Ejecute sudo chage -d 0 deploy o sudo passwd -e deploy, que hace lo mismo. La fecha de último cambio almacenada se establece en la época, PAM considera que la contraseña ha caducado y el siguiente inicio de sesión interactivo debe establecer una nueva antes de iniciar un shell. No haga esto en una cuenta que utilicen scripts mediante SSH: una orden no interactiva fallará con Password change required but no TTY available. y no llegará a ejecutarse.