Proteger SSH não é empilhar opções de hardening até o servidor “parecer seguro”. O objetivo é reduzir formas desnecessárias de autenticação e privilégio sem perder o caminho legítimo de administração. A sequência segura é: entender como o servidor está acessível hoje, preparar uma chave, testar a chave em uma segunda sessão, validar a configuração do daemon e só então remover o método antigo de acesso.
Resposta curta: endureça o acesso em etapas reversíveis
- Confirme um caminho de recuperação: console, painel da VM, acesso físico ou sessão já aberta.
- Instale/valide o OpenSSH Server pela documentação da sua distribuição.
- Crie uma chave no cliente e teste o login por chave em uma nova sessão.
- Revise a configuração efetiva antes de mudar autenticação ou usuários permitidos.
- Teste a sintaxe do
sshdantes de recarregar o serviço. - Só depois desative autenticação por senha, se o ambiente realmente permitir.
- Mantenha a sessão antiga aberta até confirmar um novo login completo.
1. Antes de editar: descubra como você recupera o servidor
Se o SSH é o único caminho de administração, uma configuração incorreta pode bloquear o próprio administrador. Em servidor virtual, confirme antes se existe console pelo provedor ou modo de recuperação. Em máquina local, confirme acesso físico. Em qualquer cenário, mantenha uma sessão SSH atual aberta durante os testes e use uma segunda sessão para validar o novo caminho.
Esse cuidado vem antes de “desativar senha”, trocar porta ou restringir usuários. Segurança que elimina o caminho de recuperação pode transformar uma correção simples em indisponibilidade.
2. Instale e confira o OpenSSH Server
No Ubuntu Server, a documentação oficial usa o pacote openssh-server. Depois da instalação, confirme que o serviço está ativo e que o equipamento está escutando antes de alterar qualquer diretiva.
sudo apt update
sudo apt install openssh-server
systemctl status ssh
ss -tlnp | grep sshO nome do pacote e do serviço pode mudar em outras distribuições. Não copie comandos de Ubuntu para Fedora, RHEL ou outra família sem consultar a documentação correspondente.
3. Gere a chave no cliente, não no servidor
A chave privada deve permanecer no dispositivo cliente. Para uma chave Ed25519, um exemplo comum é:
ssh-keygen -t ed25519 -C "administracao-servidor"Proteja a chave privada com permissões adequadas e, quando fizer sentido para o uso, com frase secreta. A parte pública pode ser adicionada ao authorized_keys do usuário remoto. O utilitáriossh-copy-id pode ajudar quando a distribuição o disponibiliza:
ssh-copy-id usuario@servidor
ssh usuario@servidorO ponto decisivo é abrir uma nova conexão e confirmar que ela usa a chave esperada antes de desligar qualquer método anterior de autenticação.
4. Veja a configuração efetiva antes de concluir o que está ativo
OpenSSH pode ler o arquivo principal e arquivos adicionais de configuração. Em Ubuntu, a documentação atual descreve o uso de snippets em /etc/ssh/sshd_config.d/. Antes de editar, descubra de onde a diretiva está vindo e evite manter valores contraditórios em mais de um arquivo.
sudo sshd -T | less
sudo grep -R "^[[:space:]]*PasswordAuthentication\|^[[:space:]]*PermitRootLogin\|^[[:space:]]*PubkeyAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/nullA saída efetiva é mais útil do que assumir que uma linha comentada representa o valor ativo.
5. Chaves primeiro; senha só é removida depois do teste
Uma política comum é permitir autenticação por chave e impedir login remoto direto como root. Em um ambiente onde todos os administradores já conseguem entrar por chave e existe recuperação fora do SSH, também pode fazer sentido desativar senha.
PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication noNão cole essas três linhas e recarregue imediatamente. A ordem segura é testar a chave, validar a configuração, manter a sessão atual aberta, recarregar e então testar uma nova conexão. Se existem automações, appliances, contas legadas ou acesso de emergência dependentes de senha, inventarie-os antes.
6. Valide a sintaxe antes de recarregar o daemon
O OpenSSH oferece teste de configuração. Use-o antes de aplicar uma alteração:
sudo sshd -tSem saída de erro, recarregue o serviço conforme a sua distribuição. No Ubuntu, o serviço normalmente éssh:
sudo systemctl reload sshDepois do reload, abra uma nova sessão do zero. Só feche a sessão antiga quando o login novo estiver confirmado.
7. Restringir usuários pode ajudar — se a lista estiver correta
Diretivas como AllowUsers e AllowGroups podem reduzir quem tem permissão para autenticar via SSH. Elas também podem bloquear toda a equipe se um usuário ou grupo for omitido. Use-as apenas quando houver inventário claro de administradores e outro caminho de recuperação.
AllowGroups ssh-adminsEm ambientes gerenciados por diretório, automação ou configuração central, confirme primeiro como os usuários e grupos chegam ao sistema.
8. Trocar a porta não substitui autenticação forte
Mudar a porta padrão pode reduzir ruído de varreduras oportunistas e volume de logs, mas não corrige senha fraca, chave vazada, usuário privilegiado ou software desatualizado. Trate a troca de porta como decisão operacional, não como o núcleo da segurança.
Se a porta mudar, atualize firewall, automações, monitoramento e clientes antes de remover a regra antiga. Faça a mudança em duas etapas e teste a nova porta com a antiga ainda disponível quando a arquitetura permitir.
9. Firewall, bloqueio de tentativas e MFA são camadas separadas
Firewall pode limitar de onde o serviço é alcançável; ferramentas de bloqueio por log podem reagir a tentativas repetidas; autenticação multifator adiciona outra exigência ao login. Nenhuma dessas camadas deve ser instalada por receita genérica sem considerar a distribuição, o provedor, o método de autenticação e a forma de recuperação.
Por isso, este guia não prescreve valores universais de banimento, uma porta específica nem um módulo PAM de terceiros. Para firewall, siga a trilha específica em como configurar firewall UFW no Linux.
10. O que revisar depois da mudança
- Uma nova sessão autentica pelo método esperado.
- O usuário administrativo tem apenas o privilégio necessário.
- O login direto como root está coerente com a política definida.
- Firewall e monitoramento conhecem a porta realmente usada.
- Logs de autenticação estão sendo coletados e revisados.
- Existe processo para revogar uma chave perdida ou de ex-funcionário.
- Existe acesso de recuperação independente do mesmo arquivo de configuração.
Quando parar e não aplicar a alteração
Pare antes de desativar senha ou recarregar o serviço se você não tem uma segunda sessão funcionando por chave, não tem console de recuperação, não sabe quais automações dependem do SSH, não consegue explicar a configuração efetiva ou encontrou erro em sshd -t. Em servidor remoto, preservar um acesso conhecido é mais importante do que concluir o hardening na mesma sessão.
Fontes oficiais consultadas
Onde este guia entra no Atlas
SSH expõe uma superfície de autenticação remota. A trilha de segurança coloca identidade, chaves, acesso mínimo, firewall e recuperação antes de receitas de hardening.