Rocky Linux / Configurar acesso SSH de root com chave pública

No Rocky Linux, a opção PermitRootLogin controla o acesso SSH da conta root. Prefira uma conta administrativa individual com sudo; se o acesso direto for necessário, exija uma chave pública e valide a política antes de recarregar o serviço e testar uma nova conexão.

Comece por uma conta administrativa individual

SSH (Secure Shell) permite administrar o servidor por uma conexão criptografada; sshd é o serviço que recebe essas conexões. Este procedimento pressupõe SSH já instalado e funcionando, privilégios administrativos e acesso ao console para recuperação. Confira a versão instalada e o manual local, pois o Rocky e suas políticas podem alterar os padrões do OpenSSH.

Uma conta por administrador facilita atribuir acessos e registrar comandos executados com sudo. Isso não equivale a gravar automaticamente toda ação feita dentro de um shell root. Se já houver uma conta adequada, use-a em vez de criar outra.

No exemplo, adminuser é um nome a substituir. Execute useradd somente se a conta ainda não existir; depois confira o diretório pessoal, o shell e a política sudo efetiva do grupo wheel.

sudo useradd adminuser
sudo usermod -aG wheel adminuser

Registre a chave pública no diretório pessoal real desse usuário e abra uma nova sessão para que a associação ao grupo seja reconhecida. Verifique tanto o login quanto sudo -v antes de fechar a conexão administrativa atual.

A chave SSH não define a senha da conta usada pelo sudo. Se a política do wheel exigir a senha do próprio usuário, prepare-a com sudo passwd adminuser e confirme o resultado nessa nova sessão. Não conceda NOPASSWD de forma ampla para contornar a autenticação. Restrições de conta, PAM (Pluggable Authentication Modules) e políticas da organização também continuam valendo.

Confira a configuração efetiva do SSH

sshd -T mostra valores efetivos, combinando o arquivo principal, arquivos incluídos e padrões. A busca com grep abaixo ajuda a localizar algumas diretivas, mas não é uma auditoria completa: não lista todas as restrições de autenticação nem prova que os arquivos encontrados foram incluídos.

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Leia também Include, AuthenticationMethods, AuthorizedKeysFile e eventuais regras de usuários e grupos. Se o diretório /etc/ssh/sshd_config.d não existir, a mensagem do grep não significa, por si só, que o serviço esteja mal configurado; confira os caminhos realmente usados.

As regras Match podem mudar o resultado para cada usuário, endereço de origem ou porta local. Use sshd -T -C com as condições reais; o resultado sem -C não basta para confirmar uma política condicional de root. Se a unidade de serviço iniciar o daemon com outro arquivo ou opções, reproduza esses parâmetros na verificação.

Prepare a chave pública do root

Arquivo, proprietário e permissões

Primeiro confira o AuthorizedKeysFile efetivo para root. O exemplo usa o caminho convencional /root/.ssh/authorized_keys; adapte-o se a instalação usar outro diretório pessoal, arquivo ou mecanismo de chaves. Guarde uma cópia do arquivo existente antes de alterá-lo e preserve as chaves e opções de outros administradores.

Substitua toda a linha ssh-ed25519 public_key_string administrator_identifier pelo conteúdo de uma chave pública real, normalmente de um arquivo .pub. O texto é um marcador inválido, não uma chave utilizável. Use um tipo de chave aceito pelo cliente, pelo servidor e pela política criptográfica instalada.

sudo install -d -m 700 -o root -g root /root/.ssh
echo 'ssh-ed25519 public_key_string administrator_identifier' | sudo tee -a /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh

tee -a acrescenta a chave, sem substituir o arquivo inteiro. Antes de executar, confira se a chave ainda não está cadastrada e se a última linha existente termina corretamente; duas chaves coladas na mesma linha não serão válidas. Verifique o resultado de cada comando antes de prosseguir. Nunca envie a chave privada ao servidor.

Os modos 700 para o diretório e 600 para o arquivo restringem o acesso; proprietário e contexto SELinux também precisam estar corretos. O guia de chaves SSH do Rocky Linux, em inglês explica os arquivos e permissões. Se houver bloqueio por SELinux, investigue a causa em vez de desativá-lo.

Restrições por chave

Para automação, opções de authorized_keys podem limitar a origem com from= e fixar a operação com command=. A opção restrict desabilita encaminhamentos, alocação de terminal e execução de ~/.ssh/rc; ela sozinha não escolhe um comando obrigatório. Combine apenas as restrições necessárias e teste com uma chave separada, conforme o manual oficial de sshd e authorized_keys.

Exija chave pública na política de root

Faça backup do arquivo principal e dos arquivos incluídos que serão alterados, preservando permissões e contexto. Registre os valores anteriores e o arquivo exato de cada mudança para poder restaurá-los sem apagar alterações de outros administradores. Inspecione a ordem de Include e os blocos Match antes de editar.

O OpenSSH usa o primeiro valor obtido para muitas opções. Dentro dos blocos Match aplicáveis, a primeira ocorrência de uma opção prevalece; os valores condicionais podem substituir os globais. Assim, um arquivo chamado 90-root.conf não ganha prioridade só pelo número. O manual oficial de sshd_config descreve essas regras.

Se já existir um bloco efetivo para root, ajuste-o. Caso contrário, o exemplo abaixo pode ficar no final de /etc/ssh/sshd_config, depois das configurações globais. Não insira um Match sem revisar o restante da estrutura: ele continua até outro Match ou o fim do arquivo, e colocá-lo num arquivo incluído no início pode mudar a interpretação das diretivas posteriores.

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

PermitRootLogin prohibit-password proíbe senha e autenticação interativa por teclado para root, mas não exige, sozinho, que todo acesso use chave pública. Neste exemplo, AuthenticationMethods publickey impõe esse método. Não substitua uma política obrigatória de autenticação multifator por esta configuração de chave única.

As linhas acima são conteúdo de configuração, não comandos de shell. Salve no bloco correto e teste primeiro a sintaxe e depois o resultado para a conexão real:

sudo sshd -t
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E "^(permitrootlogin|pubkeyauthentication|passwordauthentication|authenticationmethods) "

Troque client.example.test e 192.0.2.10 pelo nome e endereço de origem reais. Se houver condições por endereço ou porta local, informe também laddr e lport em -C. Repita a consulta com o nome do administrador comum e as condições correspondentes.

Para root, espere permitrootlogin prohibit-password, pubkeyauthentication yes e authenticationmethods publickey. passwordauthentication yes ainda pode aparecer como valor geral: com prohibit-password, a senha de root é proibida mesmo assim. Esses valores não comprovam que a chave ou a conta serão aceitas; isso exige um teste de conexão.

Valide, recarregue e teste em outra sessão

1. Mantenha a sessão administrativa atual aberta e confirme um console independente para recuperação.
2. Execute sudo sshd -t. Só prossiga se não houver erro e o estado de saída for zero; corrija o arquivo e a linha indicados em caso de falha.
3. Confira com sshd -T -C as políticas de root e do administrador comum. Só então recarregue a unidade sshd.
4. No cliente OpenSSH, teste uma conexão nova com ssh -o ControlMaster=no -o ControlPath=none -o IdentitiesOnly=yes -i /caminho/da/chave_privada -p 22 root@servidor.example.test. Substitua caminho, porta e servidor pelos valores reais; a chave privada permanece no cliente. Confira a identidade do servidor antes de aceitar uma chave de host nova.
5. Em outra tentativa, use ssh -o ControlMaster=no -o ControlPath=none -o PubkeyAuthentication=no -o PreferredAuthentications=password -p 22 root@servidor.example.test, adaptando servidor e porta. Com a política de chave pública acima, esse login somente por senha deve ser recusado. Teste também um novo login do administrador comum e seu sudo -v.

ControlPath=none evita que o cliente reutilize uma conexão multiplexada já autenticada; abrir apenas outra janela pode não criar uma autenticação nova. O manual oficial de configuração do cliente SSH explica essas opções. A frase secreta da chave privada é solicitada localmente e não é a senha da conta root no servidor.

Substitua os marcadores de conexão antes de executar este bloco. Os operadores && impedem a recarga se a validação falhar e só consultam a política depois de uma recarga bem-sucedida:

sudo sshd -t &&
sudo systemctl reload sshd &&
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods) '

A consulta final deve mostrar novamente a política esperada para root. O comando reload solicita a releitura da configuração; seu sucesso não demonstra que uma autenticação nova funcione. Não feche a sessão antiga antes dos testes. Se perder o acesso, use o console para restaurar somente as mudanças registradas, valide a configuração restaurada e recarregue o serviço.

Se a chave falhar, consulte sudo journalctl -u sshd e as condições efetivas da conta. Não desbloqueie root ou reduza a política de PAM e criptografia sem entender a causa. A disponibilidade do console deve ser confirmada antes da edição, não depois de um bloqueio.

Reduza a exposição e separe as chaves

Limite a origem no firewall

Prefira acesso por VPN ou rede de administração. No exemplo, public deve ser trocado pela zona real e 192.0.2.0/24 pela rede autorizada. Confira o endereço que o servidor realmente recebe, inclusive após NAT ou bastion, e o serviço/porta SSH que está em uso.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

Esta regra acrescenta uma permissão para a rede indicada; não bloqueia automaticamente as demais origens. Se já houver um serviço ssh, uma porta ou outra regra liberando acesso amplo, ele pode continuar permitido. Verifique IPv4 e IPv6, zonas, regras e firewall do provedor antes de afirmar que o acesso ficou restrito. A referência oficial das regras rich do firewalld descreve sua combinação.

Teste primeiro a permissão em tempo de execução, mantendo o console disponível. Após confirmar uma nova conexão da origem correta, acrescente a mesma regra com --permanent. Só remova a liberação ampla existente depois de conferir o plano de recuperação e as demais origens necessárias. Faça a alteração correspondente na configuração permanente, sem persistir ou excluir regras alheias.

Para desfazer uma permissão que você acabou de criar, use --remove-rich-rule com a mesma regra e zona, no escopo em que a adicionou; remova a versão permanente somente se também tiver sido criada por você. Não remova uma regra que já existia antes. Veja também o guia de firewalld no Rocky Linux.

Use uma chave por pessoa e finalidade

• Forneça uma chave diferente para cada administrador e revogue apenas a chave correspondente quando necessário.
• Separe chaves de automação e de administração interativa; uma conta root compartilhada ainda dificulta a atribuição individual das ações.
• Proteja a chave privada com uma frase secreta e só use encaminhamento de agente quando houver necessidade e confiança no destino.
• Centralize os registros de SSH e crie alertas para tentativas anormais de autenticação.

Trate senha de root como uma exceção temporária

Ativar PermitRootLogin yes e autenticação por senha amplia a exposição de uma conta com controle total do servidor. Se uma operação legada realmente exigir isso, delimite a origem por VPN ou rede administrativa, o período de uso e o monitoramento; preserve o acesso de recuperação e os valores anteriores.

Este exemplo altera os valores no mesmo bloco Match User root usado antes. Não o acrescente como um bloco concorrente nem como uma alteração global:

PermitRootLogin yes
PasswordAuthentication yes
AuthenticationMethods any

Deixar AuthenticationMethods publickey efetivo e apenas acrescentar yes não habilita senha como método único. Já AuthenticationMethods any aceita um método habilitado, não exige todos eles; portanto, reduz a exigência de autenticação e não preserva uma política multifator. Bloqueios de conta, PAM, regras de usuários/grupos e firewall continuam independentes.

Valide sintaxe e valores condicionais antes de recarregar e faça testes novos sem fechar a sessão atual. Ao concluir a exceção, restaure exatamente a política anterior, teste novamente e substitua ou invalide a senha temporária conforme a política de contas. Não deixe esse exemplo habilitado por conveniência.

Desative novamente o acesso direto de root

Confirme primeiro um novo login por chave do administrador comum e seu sudo. No bloco efetivo de root que você modificou, defina:

PermitRootLogin no

Evite acrescentar uma diretiva concorrente em outro arquivo. Execute sudo sshd -t e a consulta sshd -T -C com as condições reais; o resultado esperado é permitrootlogin no. Só após a validação, aplique com sudo systemctl reload sshd. Mantenha a sessão atual enquanto confirma que uma nova conexão root é rejeitada e o administrador comum continua acessando o servidor.

Diagnóstico de falhas de conexão

Referências oficiais

Consulte o manual OpenSSH de sshd_config para PermitRootLogin, AuthenticationMethods, Include e Match, e o manual de sshd para -t, -T, -C e opções de chaves. Os manuais locais da versão instalada prevalecem quando houver diferenças.