Cambio de contraseña en OVH: ¿por qué no puedo entrar a WHM?

  • Autor Autor seomexico
  • Fecha de inicio Fecha de inicio
seomexico

seomexico

Gamma
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Tengo una cuenta activa de CPANEL en Sharedlicense COM
El problema es que mi contraseña ROOT no ingresa a WHM.

Fui a OVH solicite reiniciar en rescate.
Me dieron una contraseña TEMPORAL

Me logee a SSH con putty

Puse la clave temporal y luego:

Passw root

Y asigne una nueva contraseña
Igual no me deja ingresar a WHM

Antes de PASSW ROOT debería poner otro comando?
 
¿Te sirvió? Únete a la conversación

Con tu cuenta gratis puedes responder, escribirle al autor por mensaje privado y comprar con Saldo retenido: el pago se libera cuando recibes lo acordado.

Toma 30 segundos · vuelves a este tema al terminar
Buenas. Te digo por dónde va, porque hay un detalle que engaña mucho en modo rescate.

Cuando arrancas en modo rescate, lo que tienes delante NO es tu sistema: es un Linux mínimo y tu disco está montado aparte. Si ahí escribes "passwd root", le cambias la contraseña al sistema de rescate (o a la partición montada sin entrar en ella), no al sistema real que arranca después. Por eso la cambias, entras con ella por SSH en rescate, y luego WHM no la reconoce: son dos contraseñas distintas.

Lo correcto es entrar en el sistema antes de cambiarla:

mount /dev/sdaX /mnt (la partición raíz real; si usas LVM, antes: vgchange -ay)
chroot /mnt
passwd root

Y sales con exit y desmontas antes de reiniciar en modo normal.

Segundo sospechoso, y este es el que más confunde: cPHulk. Si has fallado varias veces, cPanel bloquea tu IP por fuerza bruta y WHM te sigue diciendo que la contraseña es incorrecta aunque ya sea la buena. Se comprueba desde SSH y se quita con:

/usr/local/cpanel/scripts/cphulkdwhitelist TU_IP

Tercero: que el acceso root esté restringido. Revisa PermitRootLogin en /etc/ssh/sshd_config y el Host Access Control de cPanel (/etc/hosts.allow y /etc/hosts.deny), porque desde una IP no permitida el login falla aunque la clave sea correcta.

Y una pregunta que cambia todo el diagnóstico: ese servidor es tuyo, con acceso a la consola de OVH y al sistema, ¿o es un hosting donde tú solo tienes un usuario de cPanel? Si es lo segundo, no hay root que valga y el problema es otro.
 
Buenas. Te digo por dónde va, porque hay un detalle que engaña mucho en modo rescate.

Cuando arrancas en modo rescate, lo que tienes delante NO es tu sistema: es un Linux mínimo y tu disco está montado aparte. Si ahí escribes "passwd root", le cambias la contraseña al sistema de rescate (o a la partición montada sin entrar en ella), no al sistema real que arranca después. Por eso la cambias, entras con ella por SSH en rescate, y luego WHM no la reconoce: son dos contraseñas distintas.

Lo correcto es entrar en el sistema antes de cambiarla:

mount /dev/sdaX /mnt (la partición raíz real; si usas LVM, antes: vgchange -ay)
chroot /mnt
passwd root

Y sales con exit y desmontas antes de reiniciar en modo normal.

Segundo sospechoso, y este es el que más confunde: cPHulk. Si has fallado varias veces, cPanel bloquea tu IP por fuerza bruta y WHM te sigue diciendo que la contraseña es incorrecta aunque ya sea la buena. Se comprueba desde SSH y se quita con:

/usr/local/cpanel/scripts/cphulkdwhitelist TU_IP

Tercero: que el acceso root esté restringido. Revisa PermitRootLogin en /etc/ssh/sshd_config y el Host Access Control de cPanel (/etc/hosts.allow y /etc/hosts.deny), porque desde una IP no permitida el login falla aunque la clave sea correcta.

Y una pregunta que cambia todo el diagnóstico: ese servidor es tuyo, con acceso a la consola de OVH y al sistema, ¿o es un hosting donde tú solo tienes un usuario de cPanel? Si es lo segundo, no hay root que valga y el problema es otro.
Gracias. Con que comando desmonto?
Y segundo:

La X Puede el número 2?
mount /dev/sdaX
 
Te cuento que tuve el mismo problema hace unos dias, es super raro esto ahora en OVH, anteriormente no se presentaba ese problema.
 
Con gusto.

1) Desmontar. Cuando termines dentro del chroot, primero sales con exit (vuelves al rescate) y recién ahí:

umount /mnt

Si responde "target is busy", cierra lo que esté abierto dentro o usa umount -l /mnt. Si montaste algo más (por ejemplo /mnt/boot), se desmonta en orden inverso al que montaste.

2) Lo de la X: no lo adivines, míralo antes. Justo al arrancar en rescate, corre:

lsblk -f

Ahí sale el árbol completo con el tipo de sistema de archivos. Hay tres casos y confundirlos es exactamente lo que hace que passwd "no sirva":

  • Si /dev/sda2 aparece con ext4 (o xfs) directamente, entonces sí: mount /dev/sda2 /mnt.
  • Si /dev/sda2 aparece como lvm2 (lo normal en cPanel con AlmaLinux o CloudLinux), no montes sda2. sda2 es solo el contenedor físico; la raíz vive dentro como volumen lógico. Primero vgchange -ay, luego vuelve a mirar lsblk -f y monta el LV raíz, que suele aparecer como /dev/mapper/almalinux-root o /dev/mapper/vg-root: el que tenga el tamaño grande y ext4/xfs.
  • Si es un VPS y no un dedicado, el disco casi nunca es sda: suele ser /dev/vda o /dev/nvme0n1. Por eso fallan justo ahí los tutoriales que dicen sda: montas otra partición (o ninguna) y el passwd te cambia la contraseña de otro sitio. Esto explica el "es raro ahora en OVH": cambiaron el comportamiento del arranque de rescate.

El chequeo que te evita repetir el error, antes de tocar nada:

cat /mnt/etc/os-release

Tiene que decir tu AlmaLinux/CloudLinux del servidor, no el rescate. Si eso sale bien, entonces sí:

Insertar CODE, HTML o PHP:
chroot /mnt
passwd root
exit
umount /mnt
reboot

Y si después de eso WHM sigue diciendo "contraseña incorrecta", ya no es la contraseña: es cPHulk bloqueando tu IP (se limpia con /usr/local/cpanel/scripts/cphulkdwhitelist TU_IP) o PermitRootLogin en sshd_config.

Una última cosa para darte la línea exacta del lsblk: ¿es servidor dedicado o VPS?
 
jaja tranquilo, no estás loco ni se te rompió nada: es OVH. Y no eres el único, en estos días esto le pasó a varios (a un colega igual, misma escena con WHM). Bienvenido al club.

Lo que cambió: antes el modo rescate te montaba el disco solo y te dejaba el sistema a mano. Ahora te deja un Linux pelado y el disco sin montar, así que si uno escribe passwd root ahí, le cambia la contraseña al rescate y no al sistema real. De ahí la sensación de "la cambié, entré, y WHM dice que está mal". No está mal: son dos contraseñas distintas.

Y ojo con la trampa número dos, que es la que te come la tarde: en un VPS el disco casi nunca es /dev/sda, suele ser /dev/vda o /dev/nvme0n1. Montas "sda2" porque lo dice el tutorial, te responde que montó bien, y en realidad estás tocando otra cosa.

Para no adivinar, primero:

lsblk -f

Si sda2 (o vda2) aparece como lvm2, haz vgchange -ay y monta el volumen lógico: /dev/mapper/almalinux-root o el que tenga el tamaño grande. Y antes de tocar nada, confirma que estás en TU sistema y no en el rescate:

cat /mnt/etc/os-release

Si ahí te sale tu AlmaLinux o CloudLinux, vas bien: chroot /mnt, passwd root, exit, umount /mnt, reboot.

Y si después de eso WHM sigue diciendo "contraseña incorrecta", ya no es la contraseña: es cPHulk con tu IP bloqueada por los intentos fallidos.

Pásame la salida de lsblk -f y te marco la línea exacta. Esto se resuelve en cinco minutos, ánimo.
 
Con gusto.

1) Desmontar. Cuando termines dentro del chroot, primero sales con exit (vuelves al rescate) y recién ahí:

umount /mnt

Si responde "target is busy", cierra lo que esté abierto dentro o usa umount -l /mnt. Si montaste algo más (por ejemplo /mnt/boot), se desmonta en orden inverso al que montaste.

2) Lo de la X: no lo adivines, míralo antes. Justo al arrancar en rescate, corre:

lsblk -f

Ahí sale el árbol completo con el tipo de sistema de archivos. Hay tres casos y confundirlos es exactamente lo que hace que passwd "no sirva":

  • Si /dev/sda2 aparece con ext4 (o xfs) directamente, entonces sí: mount /dev/sda2 /mnt.
  • Si /dev/sda2 aparece como lvm2 (lo normal en cPanel con AlmaLinux o CloudLinux), no montes sda2. sda2 es solo el contenedor físico; la raíz vive dentro como volumen lógico. Primero vgchange -ay, luego vuelve a mirar lsblk -f y monta el LV raíz, que suele aparecer como /dev/mapper/almalinux-root o /dev/mapper/vg-root: el que tenga el tamaño grande y ext4/xfs.
  • Si es un VPS y no un dedicado, el disco casi nunca es sda: suele ser /dev/vda o /dev/nvme0n1. Por eso fallan justo ahí los tutoriales que dicen sda: montas otra partición (o ninguna) y el passwd te cambia la contraseña de otro sitio. Esto explica el "es raro ahora en OVH": cambiaron el comportamiento del arranque de rescate.

El chequeo que te evita repetir el error, antes de tocar nada:

cat /mnt/etc/os-release

Tiene que decir tu AlmaLinux/CloudLinux del servidor, no el rescate. Si eso sale bien, entonces sí:

Insertar CODE, HTML o PHP:
chroot /mnt
passwd root
exit
umount /mnt
reboot

Y si después de eso WHM sigue diciendo "contraseña incorrecta", ya no es la contraseña: es cPHulk bloqueando tu IP (se limpia con /usr/local/cpanel/scripts/cphulkdwhitelist TU_IP) o PermitRootLogin en sshd_config.

Una última cosa para darte la línea exacta del lsblk: ¿es servidor dedicado o VPS?
Te agradezco es VPS
 
Por lo que describes, parece que cambiaste la contraseña del entorno de rescate. Como ya te comentaron, para cambiar la del VPS hay que montar su sistema y entrar con chroot. El comando es passwd root, con dos «s» y una «d» al final.

Primero, desde PuTTY conectado al rescate, ejecuta:

Bash:
lsblk
lsblk -f

No se puede saber si es sda2 solo por ser un VPS. En el ejemplo oficial de OVH, sda es el disco del rescate y el sistema del VPS está en sdb1. En el tuyo puede ser distinto. Tampoco elijas únicamente por tamaño: la partición más grande podría ser /home.

Si has identificado una partición candidata, puedes montarla inicialmente en lectura para comprobarla. En este ejemplo uso /dev/sdb1; sustitúyelo por el dispositivo que corresponda en tu VPS, no lo copies a ciegas:

Bash:
mount -o ro /dev/sdb1 /mnt
cat /mnt/etc/os-release
cat /mnt/etc/fstab

Comprueba que es tu instalación y que la entrada de / en ese fstab corresponde al dispositivo o UUID que viste en lsblk -f. Si aparece LVM2_member, no montes esa partición directamente: necesitas el volumen lógico raíz. Si no lo tienes claro, pega la salida de lsblk antes de continuar.

Una vez confirmada la raíz del VPS, habilita escritura y entra en ella:

Bash:
mount -o remount,rw /mnt
chroot /mnt /bin/bash

Solo si el chroot terminó sin errores, cambia la clave:

Bash:
passwd root

Escríbela dos veces; que no aparezcan caracteres mientras tecleas es normal. Debe confirmar que la contraseña se actualizó. Si sale un error de permisos, de autenticación o de sistema de archivos, detente ahí y comparte ese error: no des por hecho que la cambió.

Después sales y desmontas:

Bash:
exit
cd /
sync
umount /mnt

Si dice que está ocupado, hay que revisar qué lo está usando; no recurrir de entrada a umount -l. Si habías montado otras particiones dentro de /mnt, desmóntalas primero.

Ahora, desde el panel de OVH, selecciona reiniciar el VPS en modo normal. Este paso importa: tiene que arrancar desde su disco, no volver al rescate. OVH documenta el procedimiento aquí:

Ya arrancado, prueba primero el usuario root y la nueva contraseña en la consola KVM de OVH. Luego prueba WHM en https://ip-de-tu-vps:2087 con esos mismos datos. La contraseña temporal del rescate ya no es la que debes usar.

Y una precisión sobre lo comentado arriba: PermitRootLogin pertenece a SSH; no controla el login web de WHM. Si puedes entrar por la consola pero WHM rechaza el acceso, toca revisar los registros de autenticación y cPHulk. Puede haber un bloqueo, pero no es la única explicación ni se confirma añadiendo una IP a la lista blanca. cPanel explica su diagnóstico aquí:

Con la salida de lsblk -f y el mensaje exacto que aparezca podemos concretar el paso que te está fallando, sin que publiques ninguna contraseña.
 
Atrás
Arriba