⚡ Em uma frase
Resetar a senha de root leva menos de cinco minutos com acesso físico ao teclado — e é exatamente por isso que esse tipo de acesso, na prática, equivale a ter controle total do sistema.

Esquecer a senha de root não é motivo para reinstalar o sistema. Toda distro Linux moderna permite interromper o boot no GRUB, cair num shell com privilégio total antes mesmo do login existir, e trocar a senha na mão — sem CD de recuperação, sem live USB, sem perder um único arquivo.

O procedimento muda um pouco conforme a família da distro (Debian/Ubuntu de um lado, RHEL/Fedora do outro, por causa do SELinux), mas o princípio é sempre o mesmo: quem consegue editar a linha de boot do kernel consegue pular a autenticação inteira. E é justamente esse princípio — não o comando em si — que interessa a qualquer administrador pensando em segurança de verdade.

Método 1: Ubuntu, Debian e derivados (via init=/bin/bash)

  1. Reinicie a máquina e, assim que a tela do GRUB aparecer, segure Shift (BIOS legada) ou pressione Esc repetidamente (UEFI) para impedir o boot automático.
  2. Selecione a entrada normal do sistema e pressione e para editar os parâmetros de boot.
  3. Localize a linha que começa com linux (ou linuxefi), troque ro por rw e adicione init=/bin/bash no final dela:
linux /boot/vmlinuz-6.8.0-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv rw quiet splash init=/bin/bash
  1. Pressione Ctrl+X (ou F10) para iniciar com esses parâmetros. O sistema cai direto num shell root, sem pedir senha — porque init=/bin/bash substitui o systemd por um shell puro antes de qualquer processo de autenticação existir.
  2. Confirme que a raiz está montada como leitura-escrita e troque a senha:
mount -o remount,rw /
passwd root
  1. Sincronize o disco e retome o boot normal:
sync
exec /sbin/init

(Se a máquina travar nesse último passo, um reboot -f forçado também resolve — o novo password já foi gravado em disco pelo passwd.)

Método 2: RHEL, Fedora e CentOS Stream (via rd.break + SELinux)

Distros da família Red Hat usam um initramfs baseado em dracut, então o parâmetro certo é outro — e existe um passo extra que, se pulado, deixa o sistema inacessível mesmo com a senha certa.

  1. No menu do GRUB, pressione e na entrada de boot e localize a linha linux (ou linuxefi).
  2. Remova rhgb e quiet (para ver o que está acontecendo) e adicione rd.break no final da linha.
  3. Pressione Ctrl+X para bootar. O sistema para dentro do initramfs, antes de montar a raiz real.
  4. A raiz de verdade está montada em /sysroot, só leitura. Remonte, entre nela via chroot e troque a senha:
mount -o remount,rw /sysroot
chroot /sysroot
passwd root
  1. Este passo é o que a maioria esquece: como o SELinux guarda o contexto de segurança de cada arquivo, gravar /etc/shadow fora do processo normal de boot deixa o rótulo do arquivo inconsistente. Sem corrigir isso, o login com a senha nova é recusado mesmo estando correta. A correção é forçar uma relabelagem completa no próximo boot:
touch /.autorelabel
  1. Saia do chroot e reinicie:
exit
exit

O boot seguinte demora mais que o normal — o SELinux está relabelando todo o sistema de arquivos, processo que pode levar de 5 a 15 minutos dependendo do volume de dados em disco.

  • Um detalhe que vale registrar: nenhum dos dois métodos funciona sozinho se o disco estiver com criptografia completa (LUKS) — nesse caso, o boot pede a senha de desbloqueio do volume antes mesmo do GRUB terminar de carregar o kernel, e sem ela não existe /sysroot nem / para remontar. Isso não é acidente: é a mitigação padrão da indústria contra exatamente este vetor (mais sobre isso adiante).

A relação com segurança física: por que isso não é "só um truque de sysadmin"

O detalhe que costuma passar batido é que o mesmo procedimento que resgata um administrador esquecido é, do ponto de vista de um invasor, um bypass de autenticação completo. Não existe distinção técnica entre "dono do servidor recuperando acesso" e "pessoa não autorizada com as mãos no teclado" — o GRUB não sabe quem está do outro lado do console, só sabe que alguém consegue editar a linha de boot.

Isso é, essencialmente, a Lei nº 3 das "Dez Leis Imutáveis da Segurança" da Microsoft, formulada ainda em 2008 e citada até hoje em qualquer curso sério de segurança da informação:

🛡️ Curiosidade útil
"If a bad guy has unrestricted physical access to your computer, it's not your computer anymore" — "Se um agente malicioso tem acesso físico irrestrito ao seu computador, ele deixou de ser seu computador." A lista completa nunca foi formalmente revisada pela Microsoft, mas a Lei nº 3 é a que mais aparece em auditorias de segurança física até hoje, justamente porque nenhuma correção de software resolve um problema de porta destrancada.

Em outras palavras: toda a superfície de ataque de senha, firewall e permissão de arquivo que um sysadmin passa meses blindando desmorona no instante em que alguém hostil tem alguns minutos sozinho com o gabinete da máquina. O GRUB é só o exemplo mais direto disso no Linux — mas o princípio vale para qualquer sistema operacional com um bootloader editável.

Como se proteger desse mesmo vetor

A boa notícia é que cada passo do reset acima tem uma mitigação real e amplamente usada em produção:

  • Criptografia de disco completa (LUKS) — exige uma senha antes mesmo do kernel montar qualquer partição. Sem ela, mount -o remount,rw não tem o que montar. É a defesa mais eficaz contra este vetor específico.
  • Senha no próprio GRUB (grub2-setpassword em RHEL/Fedora, ou grub-mkpasswd-pbkdf2 + edição manual do grub.cfg em Debian/Ubuntu) — impede que alguém sem essa senha sequer edite a linha de boot, mesmo sem criptografia de disco.
  • Senha de BIOS/UEFI protegendo a ordem de boot e o acesso ao menu de firmware — evita que o invasor troque a mídia de boot ou desative a senha do GRUB por fora do sistema operacional.
  • Secure Boot — dificulta o uso de um live USB alternativo para contornar a criptografia por outro caminho.
  • Controle de acesso físico ao ambiente — sala de servidores trancada, crachá, câmera, sensor de intrusão de chassi. Nenhuma configuração de software substitui isso; ela só aumenta o tempo e o esforço que o invasor precisa ter depois de já estar fisicamente na frente do equipamento.

Nenhuma dessas camadas é infalível sozinha, mas empilhadas elas transformam "alguém sentou no teclado por 5 minutos" de um comprometimento trivial em um ataque que exige planejamento, tempo e ferramentas — o suficiente para que outras defesas (monitoramento, alertas, resposta a incidente) entrem em ação antes do estrago.

🎯 O que isso muda

Para quem administra servidores Linux, o reset de senha via GRUB é uma ferramenta de recuperação legítima e bem documentada — mas ela só existe porque o modelo de ameaça do Linux (como o de praticamente todo sistema operacional) assume acesso físico confiável ao hardware. Em qualquer ambiente onde essa premissa não se sustenta — servidor em colocation compartilhado, notebook que pode ser furtado, máquina em sala sem controle de acesso — a real proteção não está em nenhuma senha de root, e sim em criptografar o disco e trancar a porta.

Fontes

OneUptime — How to Reset the Root Password on RHEL When Locked Out (04/03/2026)
https://oneuptime.com/blog/post/2026-03-04-reset-root-password-rhel-9/view

OneUptime — How to Recover Lost Root Password on Ubuntu (02/03/2026)
https://oneuptime.com/blog/post/2026-03-02-how-to-recover-lost-root-password-on-ubuntu/view

Microsoft — 10 Immutable Laws of Security, Lei nº 3 (13/03/2008)
https://learn.microsoft.com/en-us/archive/blogs/kristian/10-immutable-laws-of-security