Troca de senha na OVH: por que não consigo entrar no WHM?

  • Autor Autor seomexico
  • Data de início Data de início
Este tópico foi traduzido automaticamente do espanhol. Ver original
seomexico

seomexico

Gamma
Usuário com poucas negociações! Use sempre o saldo do ForoBeta!
Tenho uma conta ativa de CPANEL na Sharedlicense COM
O problema é que minha senha ROOT não entra no WHM.

Fui na OVH e solicitei reiniciar em rescue.
Me deram uma senha TEMPORÁRIA

Fiz login no SSH com o putty

Coloquei a senha temporária e depois:

Passw root

E defini uma nova senha
Mesmo assim não me deixa entrar no WHM

Antes de PASSW ROOT eu deveria colocar outro comando?
 
Foi útil? Participe da conversa

Com sua conta grátis você pode responder, mandar mensagem privada ao autor e comprar com Saldo retido: o pagamento é liberado quando você recebe o combinado.

Leva 30 segundos · você volta a este tópico ao terminar
Boas. Vou te dizer por onde vai, porque há um detalhe que engana muito no modo rescue.

Quando você inicia no modo rescue, o que você tem na frente NÃO é o seu sistema: é um Linux mínimo e o seu disco está montado à parte. Se ali você digita "passwd root", você muda a senha do sistema de rescue (ou da partição montada sem entrar nela), não do sistema real que inicia depois. Por isso você a muda, entra com ela por SSH no rescue, e depois o WHM não a reconhece: são duas senhas diferentes.

O correto é entrar no sistema antes de mudá-la:

mount /dev/sdaX /mnt (a partição raiz real; se você usa LVM, antes: vgchange -ay)
chroot /mnt
passwd root

E você sai com exit e desmonta antes de reiniciar no modo normal.

Segundo suspeito, e este é o que mais confunde: cPHulk. Se você errou várias vezes, o cPanel bloqueia seu IP por força bruta e o WHM continua dizendo que a senha está incorreta mesmo que já seja a certa. Isso se verifica pelo SSH e se remove com:

/usr/local/cpanel/scripts/cphulkdwhitelist TU_IP

Terceiro: que o acesso root esteja restrito. Verifique PermitRootLogin em /etc/ssh/sshd_config e o Host Access Control do cPanel (/etc/hosts.allow e /etc/hosts.deny), porque a partir de um IP não permitido o login falha mesmo que a senha esteja correta.

E uma pergunta que muda todo o diagnóstico: esse servidor é seu, com acesso ao console da OVH e ao sistema, ou é uma hospedagem onde você só tem um usuário de cPanel? Se for o segundo caso, não tem root que valha e o problema é outro.
 
Boas. Vou te dizer por onde vai, porque há um detalhe que engana muito no modo rescue.

Quando você inicia no modo rescue, o que você tem na frente NÃO é o seu sistema: é um Linux mínimo e o seu disco está montado à parte. Se ali você digita "passwd root", você muda a senha do sistema de rescue (ou da partição montada sem entrar nela), não do sistema real que inicia depois. Por isso você a muda, entra com ela por SSH no rescue, e depois o WHM não a reconhece: são duas senhas diferentes.

O correto é entrar no sistema antes de mudá-la:

mount /dev/sdaX /mnt (a partição raiz real; se você usa LVM, antes: vgchange -ay)
chroot /mnt
passwd root

E você sai com exit e desmonta antes de reiniciar no modo normal.

Segundo suspeito, e este é o que mais confunde: cPHulk. Se você errou várias vezes, o cPanel bloqueia seu IP por força bruta e o WHM continua dizendo que a senha está incorreta mesmo que já seja a certa. Isso se verifica pelo SSH e se remove com:

/usr/local/cpanel/scripts/cphulkdwhitelist TU_IP

Terceiro: que o acesso root esteja restrito. Verifique PermitRootLogin em /etc/ssh/sshd_config e o Host Access Control do cPanel (/etc/hosts.allow e /etc/hosts.deny), porque a partir de um IP não permitido o login falha mesmo que a senha esteja correta.

E uma pergunta que muda todo o diagnóstico: esse servidor é seu, com acesso ao console da OVH e ao sistema, ou é uma hospedagem onde você só tem um usuário de cPanel? Se for o segundo caso, não tem root que valha e o problema é outro.
Obrigado. Com que comando eu desmonto?
E segundo:

O X pode ser o número 2?
mount /dev/sdaX
 
Te conto que tive o mesmo problema há uns dias, é super estranho isso agora na OVH, antes esse problema não acontecia.
 
Com prazer.

1) Desmontar. Quando terminar dentro do chroot, primeiro você sai com exit (volta ao rescue) e só então:

umount /mnt

Se responder "target is busy", feche o que estiver aberto dentro ou use umount -l /mnt. Se você montou mais alguma coisa (por exemplo /mnt/boot), desmonta-se na ordem inversa à que você montou.

2) A questão do X: não adivinhe, olhe antes. Logo ao iniciar no rescue, rode:

lsblk -f

Ali aparece a árvore completa com o tipo de sistema de arquivos. Há três casos e confundi-los é exatamente o que faz com que passwd "não funcione":

  • Se /dev/sda2 aparece com ext4 (ou xfs) diretamente, então sim: mount /dev/sda2 /mnt.
  • Se /dev/sda2 aparece como lvm2 (o normal no cPanel com AlmaLinux ou CloudLinux), não monte sda2. sda2 é só o contêiner físico; a raiz vive dentro como volume lógico. Primeiro vgchange -ay, depois olhe de novo lsblk -f e monte o LV raiz, que costuma aparecer como /dev/mapper/almalinux-root ou /dev/mapper/vg-root: o que tiver o tamanho grande e ext4/xfs.
  • Se é um VPS e não um dedicado, o disco quase nunca é sda: costuma ser /dev/vda ou /dev/nvme0n1. Por isso falham justamente aí os tutoriais que dizem sda: você monta outra partição (ou nenhuma) e o passwd muda a senha de outro lugar. Isso explica o "é estranho agora na OVH": mudaram o comportamento da inicialização do rescue.

A checagem que evita você repetir o erro, antes de mexer em qualquer coisa:

cat /mnt/etc/os-release

Tem que mostrar o AlmaLinux/CloudLinux do seu servidor, não o rescue. Se isso der certo, então sim:

Inserir CODE, HTML ou PHP:
chroot /mnt
passwd root
exit
umount /mnt
reboot

E se depois disso o WHM continuar dizendo "senha incorreta", já não é a senha: é o cPHulk bloqueando seu IP (limpa-se com /usr/local/cpanel/scripts/cphulkdwhitelist TU_IP) ou PermitRootLogin em sshd_config.

Uma última coisa para te passar a linha exata do lsblk: é servidor dedicado ou VPS?
 
haha fica tranquilo, você não está louco nem quebrou nada: é a OVH. E você não é o único, nestes dias isso aconteceu com vários (com um colega também, mesma cena com o WHM). Bem-vindo ao clube.

O que mudou: antes o modo rescue montava o disco sozinho e deixava o sistema à mão. Agora deixa um Linux pelado e o disco sem montar, então se alguém digita passwd root ali, muda a senha do rescue e não do sistema real. Daí a sensação de "mudei, entrei, e o WHM diz que está errada". Não está errada: são duas senhas diferentes.

E cuidado com a armadilha número dois, que é a que come a sua tarde: num VPS o disco quase nunca é /dev/sda, costuma ser /dev/vda ou /dev/nvme0n1. Você monta "sda2" porque o tutorial diz, ele responde que montou bem, e na verdade você está mexendo em outra coisa.

Para não adivinhar, primeiro:

lsblk -f

Se sda2 (ou vda2) aparece como lvm2, faça vgchange -ay e monte o volume lógico: /dev/mapper/almalinux-root ou o que tiver o tamanho grande. E antes de mexer em qualquer coisa, confirme que você está no SEU sistema e não no rescue:

cat /mnt/etc/os-release

Se ali aparecer o seu AlmaLinux ou CloudLinux, você está indo bem: chroot /mnt, passwd root, exit, umount /mnt, reboot.

E se depois disso o WHM continuar dizendo "senha incorreta", já não é a senha: é o cPHulk com seu IP bloqueado pelas tentativas falhas.

Me passe a saída do lsblk -f e eu te indico a linha exata. Isso se resolve em cinco minutos, ânimo.
 
Com prazer.

1) Desmontar. Quando terminar dentro do chroot, primeiro você sai com exit (volta ao rescue) e só então:

umount /mnt

Se responder "target is busy", feche o que estiver aberto dentro ou use umount -l /mnt. Se você montou mais alguma coisa (por exemplo /mnt/boot), desmonta-se na ordem inversa à que você montou.

2) A questão do X: não adivinhe, olhe antes. Logo ao iniciar no rescue, rode:

lsblk -f

Ali aparece a árvore completa com o tipo de sistema de arquivos. Há três casos e confundi-los é exatamente o que faz com que passwd "não funcione":

  • Se /dev/sda2 aparece com ext4 (ou xfs) diretamente, então sim: mount /dev/sda2 /mnt.
  • Se /dev/sda2 aparece como lvm2 (o normal no cPanel com AlmaLinux ou CloudLinux), não monte sda2. sda2 é só o contêiner físico; a raiz vive dentro como volume lógico. Primeiro vgchange -ay, depois olhe de novo lsblk -f e monte o LV raiz, que costuma aparecer como /dev/mapper/almalinux-root ou /dev/mapper/vg-root: o que tiver o tamanho grande e ext4/xfs.
  • Se é um VPS e não um dedicado, o disco quase nunca é sda: costuma ser /dev/vda ou /dev/nvme0n1. Por isso falham justamente aí os tutoriais que dizem sda: você monta outra partição (ou nenhuma) e o passwd muda a senha de outro lugar. Isso explica o "é estranho agora na OVH": mudaram o comportamento da inicialização do rescue.

A checagem que evita você repetir o erro, antes de mexer em qualquer coisa:

cat /mnt/etc/os-release

Tem que mostrar o AlmaLinux/CloudLinux do seu servidor, não o rescue. Se isso der certo, então sim:

Inserir CODE, HTML ou PHP:
chroot /mnt
passwd root
exit
umount /mnt
reboot

E se depois disso o WHM continuar dizendo "senha incorreta", já não é a senha: é o cPHulk bloqueando seu IP (limpa-se com /usr/local/cpanel/scripts/cphulkdwhitelist TU_IP) ou PermitRootLogin em sshd_config.

Uma última coisa para te passar a linha exata do lsblk: é servidor dedicado ou VPS?
Agradeço, é VPS
 
Pelo que você descreve, parece que você mudou a senha do ambiente de rescue. Como já te comentaram, para mudar a do VPS é preciso montar o sistema dele e entrar com chroot. O comando é passwd root, com dois «s» e um «d» no final.

Primeiro, pelo PuTTY conectado ao rescue, execute:

Bash:
lsblk
lsblk -f

Não dá para saber se é sda2 só por ser um VPS. No exemplo oficial da OVH, sda é o disco do rescue e o sistema do VPS está em sdb1. No seu pode ser diferente. Também não escolha apenas pelo tamanho: a partição maior poderia ser /home.

Se você identificou uma partição candidata, pode montá-la inicialmente em modo leitura para verificá-la. Neste exemplo uso /dev/sdb1; substitua pelo dispositivo que corresponda no seu VPS, não copie às cegas:

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

Verifique que é a sua instalação e que a entrada de / nesse fstab corresponde ao dispositivo ou UUID que você viu no lsblk -f. Se aparecer LVM2_member, não monte essa partição diretamente: você precisa do volume lógico raiz. Se não tiver certeza, cole a saída do lsblk antes de continuar.

Uma vez confirmada a raiz do VPS, habilite a escrita e entre nela:

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

Só se o chroot terminou sem erros, mude a senha:

Bash:
passwd root

Digite-a duas vezes; é normal não aparecerem caracteres enquanto você digita. Deve confirmar que a senha foi atualizada. Se aparecer um erro de permissões, de autenticação ou de sistema de arquivos, pare aí e compartilhe esse erro: não dê como certo que ela foi mudada.

Depois você sai e desmonta:

Bash:
exit
cd /
sync
umount /mnt

Se disser que está ocupado, é preciso verificar o que o está usando; não recorrer de cara ao umount -l. Se você tinha montado outras partições dentro de /mnt, desmonte-as primeiro.

Agora, no painel da OVH, selecione reiniciar o VPS em modo normal. Este passo importa: ele tem que iniciar pelo seu disco, não voltar ao rescue. A OVH documenta o procedimento aqui:

Já iniciado, teste primeiro o usuário root e a nova senha no console KVM da OVH. Depois teste o WHM em https://ip-de-tu-vps:2087 com esses mesmos dados. A senha temporária do rescue já não é a que você deve usar.

E uma precisão sobre o que foi comentado acima: PermitRootLogin pertence ao SSH; não controla o login web do WHM. Se você consegue entrar pelo console mas o WHM rejeita o acesso, é preciso verificar os registros de autenticação e o cPHulk. Pode haver um bloqueio, mas não é a única explicação nem se confirma adicionando um IP à lista branca. O cPanel explica o diagnóstico aqui:

Com a saída do lsblk -f e a mensagem exata que aparecer podemos concretizar o passo que está falhando para você, sem que você publique nenhuma senha.
 
Pelo que você descreve, parece que você mudou a senha do ambiente de rescue. Como já te comentaram, para mudar a do VPS é preciso montar o sistema dele e entrar com chroot. O comando é passwd root, com dois «s» e um «d» no final.

Primeiro, pelo PuTTY conectado ao rescue, execute:

Bash:
lsblk
lsblk -f

Não dá para saber se é sda2 só por ser um VPS. No exemplo oficial da OVH, sda é o disco do rescue e o sistema do VPS está em sdb1. No seu pode ser diferente. Também não escolha apenas pelo tamanho: a partição maior poderia ser /home.

Se você identificou uma partição candidata, pode montá-la inicialmente em modo leitura para verificá-la. Neste exemplo uso /dev/sdb1; substitua pelo dispositivo que corresponda no seu VPS, não copie às cegas:

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

Verifique que é a sua instalação e que a entrada de / nesse fstab corresponde ao dispositivo ou UUID que você viu no lsblk -f. Se aparecer LVM2_member, não monte essa partição diretamente: você precisa do volume lógico raiz. Se não tiver certeza, cole a saída do lsblk antes de continuar.

Uma vez confirmada a raiz do VPS, habilite a escrita e entre nela:

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

Só se o chroot terminou sem erros, mude a senha:

Bash:
passwd root

Digite-a duas vezes; é normal não aparecerem caracteres enquanto você digita. Deve confirmar que a senha foi atualizada. Se aparecer um erro de permissões, de autenticação ou de sistema de arquivos, pare aí e compartilhe esse erro: não dê como certo que ela foi mudada.

Depois você sai e desmonta:

Bash:
exit
cd /
sync
umount /mnt

Se disser que está ocupado, é preciso verificar o que o está usando; não recorrer de cara ao umount -l. Se você tinha montado outras partições dentro de /mnt, desmonte-as primeiro.

Agora, no painel da OVH, selecione reiniciar o VPS em modo normal. Este passo importa: ele tem que iniciar pelo seu disco, não voltar ao rescue. A OVH documenta o procedimento aqui:

Já iniciado, teste primeiro o usuário root e a nova senha no console KVM da OVH. Depois teste o WHM em https://ip-de-tu-vps:2087 com esses mesmos dados. A senha temporária do rescue já não é a que você deve usar.

E uma precisão sobre o que foi comentado acima: PermitRootLogin pertence ao SSH; não controla o login web do WHM. Se você consegue entrar pelo console mas o WHM rejeita o acesso, é preciso verificar os registros de autenticação e o cPHulk. Pode haver um bloqueio, mas não é a única explicação nem se confirma adicionando um IP à lista branca. O cPanel explica o diagnóstico aqui:

Com a saída do lsblk -f e a mensagem exata que aparecer podemos concretizar o passo que está falhando para você, sem que você publique nenhuma senha.
Você não sabe se há problemas de rede hoje na OVH? um site meu não está aparecendo
 
Voltar
Topo