Ubuntu 22.04 Server / Entrar como root localmente e por SSH

No Ubuntu 22.04 Server, a forma habitual de trabalhar com privilégios de root é entrar com uma conta comum e executar sudo -i. O login direto como root exige verificar separadamente a senha e a política de acesso; no SSH, também é preciso conferir PermitRootLogin e os métodos de autenticação.

Privilégios de root e login direto

Root é a conta que administra todo o sistema. O Ubuntu bloqueia sua senha por padrão e permite que usuários autorizados executem sudo com suas próprias credenciais. A conta root continua existindo. Esse funcionamento está na documentação do Ubuntu sobre usuários.

Se você só precisa de um shell administrativo, use os comandos abaixo. Normalmente a autenticação usa a senha da conta comum, conforme a política sudo. Confira se whoami mostra root e, ao terminar, use exit para voltar à conta comum. Isso não ativa a senha de root nem altera a política SSH.

sudo -i
whoami
exit

Defina uma senha de root separadamente apenas se precisar entrar por senha no console ou usar su -. A primeira solicitação sudo usa a senha da conta comum; as duas seguintes definem a nova senha de root. Os caracteres digitados não aparecem na tela.

sudo passwd root
su -
whoami
exit

su - usa a senha de root recém-definida. Criar uma senha não libera automaticamente todos os métodos de login: PAM (Pluggable Authentication Modules, módulos de autenticação conectáveis) e políticas de console ou acesso remoto podem restringi-los. Veja o manual sudo do Ubuntu 22.04 para entender sudo -i.

Conferir acesso e política SSH existente

Os passos a seguir tratam do OpenSSH em um servidor Ubuntu 22.04 que você administra. Mantenha aberta a sessão SSH da conta comum e prepare um console físico ou de recuperação da nuvem. Em produção, considere primeiro o acesso com conta comum seguido de sudo. Se root direto for necessário, defina também o uso de chaves públicas e a rede de administração permitida.

Se o servidor SSH não estiver instalado, execute sudo apt update e depois sudo apt install openssh-server. Confira o serviço com sudo systemctl status ssh.service. Você precisa do endereço e da porta reais; o firewall e as regras da nuvem devem permitir esse caminho administrativo.

Faça backup da configuração e localize as diretivas antes de alterá-las. Se o nome de backup já existir, escolha outro para evitar sobrescrever. Guarde as cópias fora dos diretórios carregados por *.conf, como no exemplo.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

O arquivo do servidor é sshd_config, diferente do ssh_config do cliente. O Ubuntu 22.04 normalmente carrega /etc/ssh/sshd_config.d/*.conf primeiro. A maioria das diretivas usa o primeiro valor encontrado, então uma linha no final pode não substituir outra anterior. Examine a ordem de Include, condições Match e arquivos gerados pela nuvem; confirme os valores efetivos.

No manual sshd_config do Ubuntu 22.04, PermitRootLogin yes permite root quando as demais condições são atendidas. prohibit-password impede senha e autenticação interativa por teclado para root, mas pode permitir chaves públicas. no proíbe root por SSH. Uma linha comentada de valor padrão não revela, sozinha, a política real.

Configurar SSH de root com senha

Essa opção expõe a autenticação por senha de root; escolha-a apenas quando o ambiente administrativo exigir. Defina a senha com sudo passwd root e edite o arquivo realmente prioritário com sudoedit /etc/ssh/sshd_config ou o trecho correspondente. Abaixo está um exemplo de política, não uma instrução para acrescentar linhas cegamente ao final.

PermitRootLogin yes
PasswordAuthentication yes

PermitRootLogin yes não basta. A autenticação por senha, AuthenticationMethods, restrições de usuário ou grupo, PAM e estado da conta também precisam permitir acesso. Um PasswordAuthentication yes global pode afetar outros usuários; confira se amplia a política existente. Não desative o firewall nem remova autenticação multifator para seguir este guia.

Salvar o arquivo não conclui a aplicação. Faça a validação e o recarregamento descritos adiante antes do teste no cliente. Troque 192.0.2.20 pelo endereço real. Para outra porta que não a padrão 22, use ssh -p PORT com o número correto.

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20

Esse teste escolhe senha em vez de chave pública. Uma senha sozinha não funciona se o servidor exigir outra autenticação. Confirme a impressão digital da chave do host por um canal confiável de administração; não desative a verificação para contornar um alerta de mudança de chave.

Usar chave pública para SSH de root

Na autenticação por chave pública, o cliente guarda a chave privada e o servidor recebe apenas a pública correspondente. Ativar login por senha de root não é pré-requisito. É possível cadastrar a chave por uma sessão administrativa existente ou console, sem abrir antes SSH de root por senha.

Se o cliente não tiver uma chave adequada, gere-a com ssh-keygen -t ed25519. Escolha outro nome em vez de sobrescrever uma chave existente e proteja a privada com uma frase-senha. Cadastre a linha do arquivo público ~/.ssh/id_ed25519.pub. Nunca copie para o servidor a chave privada sem o sufixo .pub.

Na sessão administrativa já aberta no servidor, prepare as permissões como abaixo e acrescente a linha da chave pública no editor. Preserve as chaves existentes e evite duplicatas. Se escolheu outro nome de arquivo, use a chave pública correspondente.

sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys

O exemplo usa o caminho padrão de chaves autorizadas. Confira o caminho real se AuthorizedKeysFile indicar outro local. Escolha a política a seguir para impedir senha de root, ajuste diretivas anteriores conflitantes e valide.

PermitRootLogin prohibit-password
PubkeyAuthentication yes

Após validar e aplicar as configurações no servidor, conecte-se pelo cliente como abaixo. Se for solicitada a frase-senha da chave privada, use a da chave do cliente, não a senha de root. O acesso por chave também depende das políticas PAM, da conta e de acesso.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20

Validar configurações e testar uma nova sessão

1. Primeiro verifique sintaxe e condições das chaves do host no servidor. Uma verificação -t bem-sucedida normalmente não produz saída. Se houver erro, corrija o arquivo e a linha antes de recarregar. -T mostra a configuração efetiva; com -C, avalia as condições Match da conexão informada.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '

Troque 192.0.2.10 pelo endereço do cliente administrativo visto pelo servidor e admin.example pelo hostname do cliente a avaliar. Se houver Match LocalAddress ou LocalPort, informe também laddr e lport em -C. Para saídas inesperadas, investigue primeiro precedência e condições. As opções constam no manual sshd do Ubuntu 22.04.

2. Com a sintaxe válida e os valores de acordo com a política desejada, recarregue o serviço. Mantenha a sessão administrativa aberta e teste a senha ou chave em outra janela do cliente.

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

3. O serviço active não garante uma nova autenticação bem-sucedida. Na nova sessão root, confira whoami mostrando root e id -u mostrando 0. Teste também um novo login comum e sudo. Condições de usuário, chave, rede e conta ainda podem negar acesso.

Investigar falhas e reverter o acesso direto de root

Para Permission denied, examine autenticação, conta e política de acesso. Para tempo limite ou conexão recusada, examine separadamente endereço, porta, serviço e firewall. Veja eventos recentes com sudo journalctl -u ssh.service -n 50 --no-pager no servidor e autenticação com ssh -v root@192.0.2.20 no cliente. Oculte endereços, usuários e outros detalhes sensíveis antes de compartilhar logs.

Para bloquear root por SSH novamente, configure o PermitRootLogin efetivo como no, confira sshd -t e sshd -T com as condições de conexão e execute sudo systemctl reload ssh.service. Restaure também a política de senha alterada temporariamente. Reverta apenas arquivos e entradas modificados, sem sobrescrever cegamente todo o diretório de trechos.

Depois de confirmar SSH e sudo por outra conta comum, bloqueie a senha de root se a ativou nesta tarefa e não precisa mais dela. Segundo o manual passwd, -l bloqueia a senha, não todas as formas de acesso, como chaves públicas. Verifique separadamente o bloqueio SSH com PermitRootLogin no.

sudo passwd -l root

Bloquear a senha ou alterar o SSH não encerra automaticamente sessões root existentes. Termine o trabalho e feche os shells root que abriu com exit. Se precisar recuperar o acesso, use a sessão comum mantida aberta ou o console de recuperação, com base nos backups e no registro das alterações.