Anatomia de um bloqueio de acesso: por que o cockpit rejeita o root no Debian 12 e como resolver

Recentemente, enfrentei um comportamento curioso no Debian 12 (Bookworm): o painel web do Cockpit recusava terminantemente o login direto do usuário root.

À primeira vista, a solução tradicional parece simples: basta abrir o arquivo /etc/cockpit/disallowed-users e remover o root da lista de usuários bloqueados. No entanto, mesmo após salvar a alteração e reiniciar os serviços, a interface web continuava barrando a sessão com erro de autenticação genérico.

Quando a camada visual não entrega respostas claras, o caminho é descer para o nível do sistema operacional: entender como o PAM, o systemd-logind, as tabelas de Shadow/Shell e as políticas do Polkit interagem no Debian.

Aqui está o diagnóstico detalhado e as estratégias práticas para restabelecer o acesso.

1. O diagnóstico: por que remover da lista negra não foi suficiente?#

O Cockpit não realiza a validação de senhas internamente; ele delega a autenticação para o sistema operacional através dos processos cockpit-ws, cockpit-session e cockpit-bridge. A recusa do login de superusuário acontece em camadas encadeadas:

[ Navegador Web ]
       │
       ▼
[ cockpit-ws ] ──── Consulta ───► /etc/cockpit/disallowed-users
       │
       ▼
[ PAM Stack (/etc/pam.d/cockpit) ] ───► pam_listfile.so / common-auth
       │
       ▼
[ Subcamadas do SO ] ───► /etc/shadow (Hashes/Locks) & /etc/passwd (Shell valido)

A stack do PAM (/etc/pam.d/cockpit)#

Mesmo que o serviço web libere o usuário, o módulo PAM do Cockpit avalia arquivos adicionais através do pam_listfile.so:

auth    required    pam_listfile.so item=user sense=deny file=/etc/cockpit/disallowed-users onerr=succeed

Se houver qualquer inconsistência nas regras herdadas de common-auth ou módulos de restrição de console, o PAM encerra o fluxo com PAM_AUTH_ERR.

Estado da conta no shadow (/etc/shadow) e shell#

Em muitas imagens modernas do Debian 12 (especialmente em ambientes de nuvem focados em sudo), a conta do root vem sem senha definida ou com status de bloqueio (marcada com ! ou * no /etc/shadow). Além disso, o shell registrado no /etc/passwd precisa apontar para um binário interativo válido (como /bin/bash ou /bin/sh).

Para definir um hash de senha válido:

sudo passwd root

2. Depurando logs e chamadas de sistema#

Para isolar o ponto exato da falha, analisei os logs de autenticação e as chamadas de sistema do processo web.

Monitoramento de logs em tempo real#

O rastreio dos serviços acoplados ao systemd entrega o retorno exato do PAM:

journalctl -f -u cockpit -u systemd-logind

• Se o log exibir pam_unix(cockpit:auth): authentication failure, o hash no shadow ou a regra do PAM falhou.
• Se apontar mensagens relativas a securetty ou pseudo-terminais (pts/X), note que o pam_securetty se aplica primariamente a consoles locais e SSH; se aparecer aqui, indica restrições herdadas interferindo no fluxo.

Rastreio de chamadas com strace#

Anexando o strace ao processo do Cockpit Web Service para inspecionar os arquivos acessados durante o clique de login:

strace -f -p $(pgrep cockpit-ws) -e openat,access,connect 2>&1 | grep -E "shadow|pam|disallowed"

Após ajustar os arquivos, reiniciei os sockets do serviço:

systemctl restart cockpit.socket cockpit.service

3. A solução estrutural: usuário administrativo com elevação polkit#

Logar diretamente com a conta de root na interface web não é o padrão recomendado para ambientes compartilhados ou auditáveis. O design nativo do Cockpit foi feito para que usuários locais autentiquem sem privilégios e elevem permissões sob demanda via Polkit e Sudoers.

Passo 1: Criação do usuário local#

Utilizei o adduser para garantir a geração automática da pasta de usuário (/home/percio), esqueleto de arquivos e permissões:

adduser percio

O sistema aloca o próximo UID disponível (>= 1000), grava a entrada no /etc/passwd e armazena o hash criptografado no /etc/shadow.

Passo 2: Adicionando ao grupo sudo#

Para conceder permissões administrativas:

usermod -aG sudo percio

Como isso resolve a autenticação no cockpit?#

1. O usuário percio não consta em /etc/cockpit/disallowed-users.
2. O cockpit-bridge inicia a sessão como usuário comum não privilegiado.
3. As políticas padrão do Polkit e do arquivo sudoers autorizam a elevação.
4. Na interface web, o Cockpit habilita o botão "Acesso Administrativo" (Privileged), permitindo executar tarefas de root de forma controlada.

Abordagem alternativa: paridade direta de UID 0#

Também é possível forçar o usuário a assumir UID 0, replicando a identidade de root no nível de Kernel:

usermod -u 0 -g 0 -o percio

• -u 0: Atribui o User ID como 0.
• -g 0: Atribui o Group ID primário como 0.
• -o: Permite duplicidade de UID (non-unique).

Atenção: Embora conceda acesso total imediato, essa abordagem confunde ferramentas de auditoria (auditd e systemd-journal) e mistura a titularidade de arquivos (ownership) na home do usuário, já que o Kernel enxerga apenas o UID 0. Mantenha este método estritamente como curiosidade técnica ou último recurso de contingência.

4. Validação e estrutura de chaves SSH#

Para validar se o provisionamento ficou completo:

# 1. Conferir UID, GID e grupos
id percio

# 2. Testar elevacao de privilegios
su - percio -c "sudo whoami"
# Retorno esperado: root

# 3. Verificar o status da sessao no logind
loginctl user-status percio

Se o acesso for realizado via chaves públicas SSH, configure as permissões da pasta .ssh:

mkdir -p /home/percio/.ssh
chmod 700 /home/percio/.ssh
cp /root/.ssh/authorized_keys /home/percio/.ssh/
chown -R percio:percio /home/percio/.ssh
chmod 600 /home/percio/.ssh/authorized_keys

Conclusão: pontos centrais do diagnóstico#

Quando o Cockpit rejeitar o login de root no Debian 12:

1. Apenas editar /etc/cockpit/disallowed-users não basta se a conta estiver travada no /etc/shadow ou sem senha definida (passwd root).
2. A solução mais limpa e alinhada ao design do Cockpit é utilizar um usuário dedicado no grupo sudo, permitindo que o Polkit gerencie a elevação de privilégios diretamente pela interface gráfica.

Veja também

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Linux Como resolver o erro 'cannot refresh cache whilst offline' no Linux e cPanel

Linux Desmistificando o tmpfs: reduzir partições temporárias realmente libera RAM no Linux?

Este post está licenciado sob CC BY-NC.