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

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) como un usuario que pueda ejecutar sudo y ejecuta sudo passwd root. El comando solicita la nueva contraseña dos veces 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. 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 trata de los problemas habituales: comprobar que la nueva contraseña funciona antes de perder la sesión que podría permitirte corregir el problema, establecer contraseñas desde un script, hacer que una contraseña caduque 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 errores de esta guía se corrigen en dos minutos mientras todavía haya un shell autenticado activo. Si se cierra el último shell, es posible que tenga que acceder a la consola.

Un shell que ya está abierto sigue funcionando después de cambiar, bloquear o caducar la cuenta a la que pertenece. 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 conectables de autenticación) 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 durante el inicio de 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 se reemplazó el hash de /etc/shadow. Cualquier otra salida significa que la contraseña anterior sigue activa.

Aquí pueden producirse dos errores. passwd: Authentication token manipulation error, seguido de passwd: password unchanged, indica que la contraseña actual introducida es 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, solo 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

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

El bloqueo es una acción independiente. sudo passwd -l deploy coloca un ! delante del 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 ese usuario inicie sesión. Cualquier clave de su archivo ~/.ssh/authorized_keys seguirá funcionando, porque la autenticación mediante clave pública nunca consulta /etc/shadow. Para bloquear completamente una cuenta, haga que la 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 anterior 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 empieza por root L. Nadie puede iniciar sesión como root con una contraseña hasta que establezca una. Por eso la imagen le proporciona un usuario con permisos de sudo. Trabajar con cuentas de usuario con privilegios mínimos en un VPS en lugar de hacerlo como root es el patrón que debe mantener.

Establecer una contraseña para root proporciona una cosa 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 eso 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 solo se permiten claves. Compruebe qué usa 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 tanto, 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 la 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 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. La contraseña en texto plano nunca sale del equipo donde se escribió.

Ubuntu 24.04 genera hashes de contraseñas nuevas con yescrypt ($y$) cuando passwd las establece, mientras que openssl passwd -6 usa SHA-512. Ambos formatos se validan durante el inicio de sesión porque libxcrypt lee los dos formatos. Se pueden mezclar, y openssl passwd -6 funciona de la misma forma en todas las versiones Ubuntu LTS, a diferencia de chpasswd -c YESCRYPT: el paquete shadow anterior de 20.04 no conoce ese nombre de método.

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

Empiece por los metadatos y después confírmelo con un inicio de sesión.

sudo passwd -S deploy

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

El segundo campo es el estado: P para una contraseña utilizable, L para una contraseña 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 son los campos de caducidad descritos más abajo.

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

sudo -k && sudo -v

Para probar otra cuenta, ejecute su - deploy desde un shell sin privilegios. No ejecute sudo su - deploy, porque root nunca recibe una solicitud de contraseña y la prueba no demuestra nada. Una contraseña incorrecta muestra su: Authentication failure.

La prueba real es 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 le 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 solo 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 una clave realizó 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 solo 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 son 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 inmediatamente 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 después de 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 estricta e independiente de la contraseña.

sudo chage -M 90 -W 14 deploy

Establezca este valor solo cuando una política lo requiera. NIST (el National Institute of Standards and Technology de Estados Unidos) desaconseja desde 2017 la caducidad rutinaria de las contraseñas, porque lleva a las personas a crear variaciones predecibles de una misma contraseña. En su lugar, recomienda forzar un 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 se pierde 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 funcional.

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 supervise la consola.
2. Acceda al menú de GRUB. Las imágenes en la nube suelen establecer GRUB_TIMEOUT=0, así que mantenga pulsado Shift durante un arranque BIOS o pulse Esc repetidamente 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 /. El modo de recuperación monta el sistema de archivos raíz como 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, después, reinicie desde el panel.

Si root ya tiene una contraseña y esa es la que ha perdido, el shell de recuperación se la solicitará y este procedimiento no funcionará. Inicie 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 las 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 la tecla de bloqueo de mayúsculas esté activada o que la distribución del teclado de la consola sea diferente 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 sitio. En Ubuntu 22.04 y versiones posteriores, normalmente se encuentra en un archivo adicional dentro de /etc/ssh/sshd_config.d/ que prevalece sobre 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 activado el otro es la causa de que un servidor que parece aceptar únicamente claves siga aceptando contraseñas escritas.

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 supervisando SSH bloqueó su dirección después de varios intentos fallidos. La regla de bloqueo predeterminada rechaza el paquete en lugar de descartarlo. Por eso el rechazo llega rápidamente en vez de agotar 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 desbloquea 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 parte 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 la configuración de sshd que conviene cambiar, y Los primeros diez minutos en un VPS nuevo indica el orden en que debe aplicar estos cambios en un servidor recién instalado.

Conserve una contraseña después de eso. Un servidor que solo usa claves y tiene una configuración de sshd dañada solo se puede alcanzar mediante la consola del proveedor, que solicita un nombre de usuario y una contraseña. Una cuenta con una contraseña segura que haya guardado es lo que separa una correcció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?

Inicia sesión como un usuario que pueda ejecutar sudo y ejecuta sudo passwd root. Esto establece una contraseña nueva sin solicitar la anterior, porque sudo ya te autenticó. Si ninguna cuenta del servidor puede ejecutar sudo, abre la consola del proveedor, reinicia en el menú de recuperación de GRUB, selecciona la entrada de shell root, ejecuta mount -o remount,rw / y, después, passwd. Si root ya tiene una contraseña y esa es la que perdiste, el shell de recuperación la solicita. En ese caso, la alternativa restante es usar la imagen de rescate del proveedor, montar el disco y ejecutar chroot.

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

Dos causas producen ese mensaje. La más común 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. Ejecuta mount -o remount,rw / e inténtalo de nuevo.

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

Sí. sudo no tiene una contraseña propia. Te autentica mediante PAM contra la misma entrada de /etc/shadow que usan SSH y su. Por tanto, cada cuenta tiene una sola contraseña. Por eso, el primer indicador de sudo después del cambio es la prueba real. Ejecuta sudo -k && sudo -v para forzar ese indicador mientras aún tienes una sesión funcional.

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

No. La autenticación mediante clave pública nunca lee /etc/shadow. Por tanto, 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 solo al iniciar sesión. El único cambio dentro de una sesión activa afecta a 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?

Ejecuta 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 Unix. PAM trata la contraseña como caducada y el siguiente inicio de sesión interactivo debe establecer una nueva antes de iniciar el shell. No hagas esto con una cuenta que usen scripts mediante SSH: una orden no interactiva falla con Password change required but no TTY available. y nunca se ejecuta.