Cambiar la contraseña de root en un VPS Ubuntu

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

Para cambiar la contraseña de root de tu VPS (servidor privado virtual) en Ubuntu, abre una sesión SSH (shell seguro) con un usuario que pueda ejecutar sudo y, después, ejecuta sudo passwd root. El comando solicita dos veces la contraseña nueva y nunca solicita la anterior porque sudo ya ha verificado tu identidad. Para cambiar tu propia contraseña de inicio de sesión, ejecuta passwd sin argumentos. En ese caso, el comando solicita primero tu 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 cubre los problemas habituales: comprobar que la contraseña nueva funciona antes de perder la sesión que podría permitirte corregirla, establecer contraseñas desde un script, caducar una contraseña de forma intencionada y volver a acceder cuando ya se ha perdido la contraseña.

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 corrigen en dos minutos mientras haya un shell autenticado activo, y requieren acceder a la consola cuando se cierra el último.

Un shell que ya está abierto sigue funcionando después de cambiar, bloquear o hacer caducar la cuenta a la que pertenece, porque SSH comprueba las credenciales al iniciar sesión y no vuelve a comprobarlas. 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 de la última solicitud 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 la primera permanece abierta.

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 la única salida que indica que el hash de /etc/shadow se reemplazó. Cualquier otra salida deja la contraseña anterior sin cambios.

Aquí pueden producirse dos errores. passwd: Authentication token manipulation error, seguido de passwd: password unchanged, indica que la contraseña actual que escribiste 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 tu proveedor) no tiene contraseña, sólo una clave SSH. passwd no tiene una contraseña actual que comprobar, por lo que no puede superar el primer aviso. Usa 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

No se solicita la contraseña antigua de root y pam_unix omite las comprobaciones de seguridad 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 coloca un ! delante del hash almacenado, de modo que ninguna contraseña coincida con él. sudo passwd -u deploy lo elimina. Consulte el estado con sudo passwd -S deploy.

Bloquear la contraseña no impide que ese usuario inicie sesión. Cualquier clave de su archivo ~/.ssh/authorized_keys sigue funcionando, porque la autenticación mediante 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 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 de 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. Nada 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. El patrón que debe mantenerse es 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 posibilidad concreta: acceder 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 menú de recuperación de GRUB solicita la contraseña de root cuando root tiene una, de modo que 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 auxiliares.

Establecer una contraseña desde un script con chpasswd

passwd lee desde el terminal y no se puede ejecutar 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 introduce 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 SHA-512 crypt que empieza por $6$. -e indica a chpasswd que el segundo campo ya contiene 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 la contraseña en texto plano nunca sale del equipo donde la introdujo.

Ubuntu 24.04 genera hashes yescrypt ($y$) para las contraseñas nuevas cuando passwd las establece, mientras que openssl passwd -6 usa SHA-512. Ambos se validan durante el inicio de sesión porque libxcrypt admite los dos formatos. Se pueden mezclar, y openssl passwd -6 se comporta igual en todas las versiones LTS de Ubuntu, pero chpasswd -c YESCRYPT no: el paquete shadow anterior 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 las contraseñas.

¿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 indica el estado: P para una contraseña utilizable, L para una cuenta bloqueada y NP cuando no hay ninguna contraseña. La fecha indica cuándo se cambió la contraseña por última vez, por lo que debería mostrar la fecha de hoy. Los números que aparecen después corresponden a los campos de caducidad descritos más abajo.

La prueba en el sistema en ejecución más segura es sudo. sudo -k descarta la marca de tiempo almacenada en caché y sudo -v fuerza una solicitud nueva. Si acepta la contraseña nueva, PAM la validó y la sesión 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 root nunca debe introducir una contraseña y la prueba no demuestra nada. Una contraseña incorrecta muestra su: Authentication failure.

La prueba real consiste en iniciar una sesión SSH nueva desde su 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, 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 para cuentas que inicien sesión de forma interactiva con 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 una clave ha realizado la autenticación. Un ssh deploy@203.0.113.10 'systemctl restart app' ejecutado mediante un script 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 evita que alguien 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 advertencia (chage -W) indican cuándo los inicios de sesión empiezan a mostrar una advertencia. Los días de inactividad (chage -I) son el período de gracia posterior a la caducidad, antes de que la contraseña deje de aceptarse por completo. La caducidad de la cuenta (chage -E) es una fecha límite fija e independiente de la contraseña.

sudo chage -M 90 -W 14 deploy

Establezca este valor sólo cuando una política lo requiera. Desde 2017, NIST (el National Institute of Standards and Technology de Estados Unidos) desaconseja la caducidad periódica de las contraseñas, porque empuja a las personas a usar variaciones predecibles de una misma contraseña. En su lugar, recomienda forzar un cambio cuando existan indicios de compromiso. 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 si 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 la afectan.

1. Reinicie el servidor desde el panel y observe la consola.
2. Abra el menú de GRUB. Las imágenes cloud suelen establecer GRUB_TIMEOUT=0, por lo que debe mantener pulsada Shift durante un arranque BIOS o pulsar Esc varias veces durante un arranque UEFI, en cuanto comience el reinicio.
3. Seleccione Advanced options for Ubuntu, después la entrada que termina en (recovery mode) y, por último, root en el menú de recuperación.
4. Ejecute primero mount -o remount,rw /. El modo de 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 /etc/shadow.
5. Ejecute passwd ubuntu para la cuenta que necesite y reinicie después desde el panel.

Si root ya tiene una contraseña y esa es la que ha perdido, ese shell de recuperación se la solicitará y no podrá continuar por esta vía. Arranque en su lugar la imagen de rescate del proveedor, monte el disco real y cambie la contraseña dentro de él.

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 que Bloq Mayús esté activado 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. 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 utiliza la misma pila PAM. Desactivar uno y dejar el otro activo hace que un servidor que parece aceptar sólo claves siga aceptando contraseñas introducidas manualmente.

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 que 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 supervisa SSH y bloqueó su dirección después de varios fallos. La regla de bloqueo predeterminada rechaza el paquete en lugar de descartarlo, por lo que la denegación se recibe 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 el bloqueo de la suya.

Las contraseñas son un paso intermedio; las claves son el objetivo 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 y los intentos de adivinación dejarán 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 ajustes de sshd que conviene cambiar, y los primeros diez minutos en un VPS nuevo los ordena para aplicarlos en un servidor recién instalado.

Conserve una contraseña después de eso. Un servidor que sólo acepta claves y tiene una configuración de sshd defectuosa sólo se puede alcanzar mediante la consola del proveedor, y esa consola solicita un nombre de usuario y una contraseña. Una cuenta con una contraseña segura que haya almacenado es lo que marca la diferencia entre una reparación de cinco minutos y 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 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 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"?

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 ha escrito 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 / e inténtelo de nuevo.

¿Cambiar mi 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 utilizan 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 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. 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 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 almacenada del último cambio se establece en la época Unix, 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 lo haga en una cuenta utilizada por scripts mediante SSH: una orden no interactiva fallará con Password change required but no TTY available. y no se ejecutará.