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.

Abre una segunda sesión antes de modificar una contraseña

Abre ahora una segunda sesión SSH y déjala conectada. Casi todos los fallos de esta guía se corrigen en dos minutos mientras haya un shell autenticado activo, pero requieren acceder a la consola cuando se cierra el último.

Un shell que ya está abierto sigue funcionando después de cambiar, bloquear o caducar la cuenta a la que pertenece, porque SSH comprueba las credenciales durante el inicio de sesión y no vuelve a comprobarlas. La excepción es sudo. Vuelve a comprobar la contraseña mediante PAM (módulos de autenticación conectables) cuando caducan sus credenciales en caché, después de 15 minutos de forma predeterminada en Ubuntu. Ese intervalo no se cuenta desde el último indicador, porque sudo -v actualiza las credenciales en caché sin volver a solicitarlas. Por tanto, la nueva contraseña se prueba realmente la próxima vez que sudo la solicita, no durante el inicio de sesión.

Prueba la nueva contraseña en la segunda sesión mientras mantienes 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 ~/.ssh/authorized_keys sigue funcionando, porque la autenticación mediante clave pública no comprueba el hash de la contraseña. Para bloquear 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 independientemente de la credencial ofrecida. Deshaga el cambio con sudo usermod --expiredate '' deploy.

Evite passwd -d. Establece una contraseña vacía en lugar de bloquearla. 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 se puede controlar 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

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 tiene un hash, por lo que se copia sin cambios en /etc/shadow. El hash se puede guardar de forma segura en un repositorio o en una variable de CI, y el texto plano nunca sale del equipo donde lo ha escrito.

Ubuntu 24.04 aplica yescrypt ($y$) a las contraseñas nuevas cuando passwd las establece, mientras que openssl passwd -6 genera SHA-512. Ambos formatos se validan al iniciar sesión porque libxcrypt lee los dos. Se pueden mezclar sin problemas, y openssl passwd -6 se comporta igual en todas las versiones LTS de Ubuntu desde 18.04, pero chpasswd -c YESCRYPT no: el paquete shadow antiguo de 20.04 no reconoce ese nombre de método. Ubuntu 16.04 es la excepción porque su OpenSSL 1.0.2 no tiene ninguna opción -6. 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 ningún usuario.

¿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 trata la contraseña como caducada. En el siguiente inicio de sesión interactivo, el sistema 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 una contraseña. Una contraseña caducada también afecta a los inicios de sesión basados en claves, porque sshd ejecuta la fase de cuenta de PAM incluso cuando la autenticación se realizó con una clave. Un ssh deploy@203.0.113.10 'systemctl restart app' ejecutado desde un script falla con este mensaje antes de ejecutar el comando:

Password change required but no TTY available.

El comando remoto no llega a ejecutarse y ssh termina con un código distinto de cero. Si el script que lo invoca no se detiene ante los errores, mediante set -e o una comprobación explícita, las líneas posteriores se siguen ejecutando y el trabajo puede finalizar como si el reinicio se hubiera realizado.

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 aún 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 que esté activado el bloqueo de mayúsculas o que la distribución del teclado de la consola sea distinta de la que usó al establecer la contraseña.

Permission denied (publickey). significa que el servidor nunca ofreció autenticación mediante contraseña, por lo que el valor efectivo es PasswordAuthentication no. Ese no puede estar en el archivo principal o en un drop-in, así que compruebe ambos. sshd lee los archivos de /etc/ssh/sshd_config.d/ al principio de su configuración y conserva el primer valor que encuentra para cada palabra clave, por lo que un drop-in reemplaza /etc/ssh/sshd_config. En servidores Ubuntu 24.04 instalados desde la ISO con SSH habilitado, a menudo ocurre lo contrario: el instalador deja un drop-in de cloud-init, 50-cloud-init.conf, que establece PasswordAuthentication yes, y después se ignora un no añadido al archivo principal. Consulte 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 interactivo mediante teclado 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 mediante el teclado.

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

Too many authentication failures en un mensaje de desconexión significa que la conexión agotó el límite de MaxAuthTries intentos del servidor, que es de 6 de forma predeterminada. La causa habitual es un cliente que ofreció varias claves antes de llegar a la contraseña. 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 suele significar que fail2ban estaba supervisando SSH y bloqueó su dirección después de varios fallos. Su regla de bloqueo predeterminada rechaza el paquete en lugar de descartarlo, por lo que la denegación llega rápidamente y no se agota el 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 el bloqueo de 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. Esto establece una contraseña nueva sin solicitar la anterior, porque sudo ya le autenticó. 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 perdió, 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"?

Hay dos causas para ese mensaje. 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 escritura. Esto ocurre en el modo de recuperación porque / está montado como de solo lectura. Ejecute mount -o remount,rw / y vuelva a intentarlo.

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

Sí. sudo no tiene una contraseña propia. Le autentica mediante PAM contra la misma entrada de /etc/shadow que usan SSH y su, por lo que cada cuenta tiene una sola contraseña. Por eso el primer indicador 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 funcional.

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

Un cambio de contraseña o passwd -l no las rompe. La autenticación mediante clave pública no comprueba el hash de la contraseña, por lo que las claves siguen funcionando después de cualquiera de las dos operaciones. chage -d 0 es diferente: sshd sigue ejecutando las comprobaciones de cuenta de PAM después de un inicio de sesión con clave. Estas comprobaciones leen los campos de caducidad de la contraseña en /etc/shadow. Por tanto, una contraseña caducada hace que un inicio de sesión con clave solicite una contraseña nueva y provoca que fallen los comandos SSH ejecutados mediante scripts. Las sesiones que ya están abiertas permanecen abiertas porque SSH comprueba las credenciales únicamente al iniciar sesión. Lo único 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 la contraseña en el siguiente inicio de sesión?

Ejecute sudo chage -d 0 deploy o sudo passwd -e deploy, que hacen lo mismo. La fecha de último cambio almacenada se establece en la época. PAM trata la contraseña como caducada y el siguiente inicio de sesión interactivo debe establecer una nueva antes de iniciar un shell. No haga esto con una cuenta utilizada por scripts mediante SSH. En ese caso, un comando no interactivo falla con Password change required but no TTY available. y nunca se ejecuta.