Configuração Avançada do Servidor SSH

Nota: Este é o quarto tutorial da série sobre SSH. Se você perdeu o anterior sobre autenticação por chaves públicas, pode encontrá-lo aqui: Autenticação SSH por Chaves Públicas.

Nos tutoriais anteriores, focamos principalmente no lado do cliente SSH e na autenticação. Agora, vamos mudar nosso foco para o coração do serviço no lado do servidor: o daemon SSH (sshd) e seu arquivo de configuração principal, sshd_config. Este arquivo permite ajustar finamente o comportamento do servidor SSH, reforçar a segurança, controlar o acesso e otimizar o desempenho.

Dominar as opções do sshd_config é essencial para qualquer administrador de sistemas que queira garantir que seus servidores SSH estejam robustos e seguros.

Localização e Edição do sshd_config

O arquivo de configuração principal do servidor OpenSSH está quase universalmente localizado em:

/etc/ssh/sshd_config

(Não confunda com /etc/ssh/ssh_config, que é o arquivo de configuração padrão para o cliente SSH em todo o sistema).

Para editar este arquivo, você precisará de privilégios de superusuário (root), pois ele controla um serviço fundamental do sistema. Use seu editor de texto preferido com sudo:

# Usando nano (amigável para iniciantes)
sudo nano /etc/ssh/sshd_config

# Usando vim (poderoso, mas com curva de aprendizado)
sudo vim /etc/ssh/sshd_config

O arquivo sshd_config consiste em diretivas de configuração, uma por linha, no formato Diretiva Valor. Linhas que começam com # são comentários e são ignoradas pelo sshd.

Importante: Reiniciar/Recarregar o Serviço sshd

Qualquer alteração feita no arquivo /etc/ssh/sshd_config não terá efeito até que você reinicie ou recarregue o serviço sshd.

• Recarregar (Reload): Geralmente preferível, pois aplica as novas configurações sem derrubar as conexões SSH existentes.

  sudo systemctl reload sshd
  # ou em sistemas sem systemd:
  # sudo service ssh reload
  

• Reiniciar (Restart): Aplica as novas configurações, mas derruba todas as conexões SSH ativas.

  sudo systemctl restart sshd
  # ou em sistemas sem systemd:
  # sudo service ssh restart
  # ou
  # sudo /etc/init.d/ssh restart
  

Dica: Antes de reiniciar/recarregar, especialmente se estiver fazendo alterações significativas remotamente, é uma boa prática verificar a sintaxe do arquivo de configuração para evitar erros que possam impedir o sshd de iniciar:

sudo sshd -t

Se a sintaxe estiver correta, ele não exibirá nenhuma saída. Se houver erros, ele indicará a linha e o problema.

Configurações Essenciais de Segurança

Estas são algumas das diretivas mais importantes para fortalecer a segurança do seu servidor SSH:

• Port <numero>:
  • Define a porta TCP na qual o sshd escutará por conexões. O padrão é 22.
  • Alterar a porta (ex: Port 2222) é uma forma de ofuscação. Não impede ataques direcionados, mas pode reduzir significativamente o ruído de bots e scanners automatizados que procuram apenas a porta 22.
  • Se você alterar a porta, lembre-se de ajustar as regras de firewall e de usar a flag -p no cliente (ssh -p 2222 ...).
• PermitRootLogin no:
  • ALTAMENTE RECOMENDADO! Controla se o usuário root pode fazer login diretamente via SSH.
  • Definir como no impede logins diretos como root. Os administradores devem fazer login como um usuário normal e usar sudo ou su para obter privilégios elevados. Isso melhora a auditoria (fica registrado qual usuário executou qual comando sudo) e reduz a superfície de ataque.
  • Outras opções (menos seguras): prohibit-password (permite root login apenas com chave pública), yes (permite login de root com qualquer método - não recomendado).
• PasswordAuthentication no:
  • Como vimos no tutorial anterior, esta diretiva desabilita completamente a autenticação baseada em senhas.
  • Defina como no após garantir que a autenticação por chave pública está funcionando para todos os usuários necessários. Isso elimina a ameaça de ataques de força bruta contra senhas.
• PubkeyAuthentication yes:
  • Garante que a autenticação usando chaves públicas esteja habilitada. Geralmente é o padrão (yes), mas é bom verificar, especialmente se você desabilitou a autenticação por senha.

Controle de Acesso

Você pode restringir quais usuários ou grupos podem se conectar via SSH:

• AllowUsers <usuario1> <usuario2> ...:
  • Se esta diretiva for usada, apenas os usuários listados poderão fazer login via SSH. Todos os outros serão negados.
  • Você pode listar usuários separados por espaços. Padrões com * e ? podem ser usados.
  • Exemplo: AllowUsers alice bob charlie@*.exemplo.com (permite alice, bob e charlie de qualquer host no domínio exemplo.com).
• DenyUsers <usuario1> <usuario2> ...:
  • Lista usuários que são explicitamente proibidos de fazer login via SSH.
  • Processado após AllowUsers.
• AllowGroups <grupo1> <grupo2> ...:
  • Se usada, apenas usuários que são membros primários ou secundários de pelo menos um dos grupos listados podem fazer login.
• DenyGroups <grupo1> <grupo2> ...:
  • Usuários pertencentes a qualquer um dos grupos listados são proibidos de fazer login.
  • Processado após AllowGroups.

Ordem de Processamento: DenyUsers -> AllowUsers -> DenyGroups -> AllowGroups. A primeira regra que corresponder determina o acesso. Recomendação: Usar AllowUsers ou AllowGroups é geralmente mais seguro (princípio do menor privilégio) do que depender de listas de negação (Deny*).

Configurações de Robustez e Performance

Estas diretivas ajudam a tornar o servidor mais resistente a abusos e podem otimizar as conexões:

• MaxAuthTries <numero>:
  • Define o número máximo de tentativas de autenticação permitidas por conexão antes que o servidor desconecte o cliente.
  • O padrão costuma ser 6. Reduzir este valor (ex: MaxAuthTries 3) pode ajudar a mitigar ataques de força bruta, desconectando atacantes mais rapidamente.
• LoginGraceTime <tempo>:
  • Define o tempo máximo (em segundos, ou formato como 1m para 1 minuto) que um cliente tem para se autenticar com sucesso após iniciar a conexão.
  • O padrão costuma ser 2m (120 segundos). Reduzir este valor (ex: LoginGraceTime 60s) pode liberar recursos do servidor mais rapidamente de conexões não autenticadas ou lentas.
• ClientAliveInterval <segundos> e ClientAliveCountMax <numero>:
  • Controlam o mecanismo de “keep-alive” do lado do servidor. Útil para detectar e fechar conexões que morreram sem um logout limpo (ex: cliente perdeu rede, travou) e para manter conexões ativas através de firewalls stateful ou NATs que podem fechar conexões TCP inativas.
  • ClientAliveInterval: O servidor enviará uma mensagem “null packet” para o cliente a cada <segundos>. Se não receber resposta, ele tentará novamente.
  • ClientAliveCountMax: O número máximo de mensagens “client alive” que podem ser enviadas sem receber uma resposta do cliente antes que o servidor desconecte a sessão.
  • Exemplo: ClientAliveInterval 60 e ClientAliveCountMax 3 significa que o servidor verificará a cada 60 segundos. Se o cliente não responder por 3 vezes consecutivas (total de 180 segundos), a conexão será encerrada.
• UseDNS no:
  • Controla se o sshd tenta fazer uma busca DNS reversa no endereço IP do cliente para encontrar seu nome de host (usado para logging e potencialmente para regras de acesso baseadas em nome).
  • Se a resolução DNS reversa for lenta ou não confiável na sua rede, definir UseDNS no pode acelerar significativamente o início das conexões SSH, pois o servidor não precisará esperar pela resposta do DNS.
  • A desvantagem é que os logs mostrarão apenas endereços IP, não nomes de host.

Outras Diretivas Úteis

• Banner /caminho/para/arquivo_de_aviso:
  • Especifica um arquivo cujo conteúdo será exibido ao usuário antes da solicitação de autenticação (senha ou chave).
  • Útil para exibir avisos legais, políticas de uso aceitável ou mensagens de manutenção.
  • Exemplo: Banner /etc/issue.net (um arquivo comum para isso em muitas distros).
• AllowTcpForwarding yes/no:
  • Controla se o tunelamento de portas (Port Forwarding - -L, -R, -D) é permitido.
  • O padrão é yes. Se você não precisa ou não quer permitir tunelamento por questões de segurança (pois pode ser usado para bypassar firewalls), defina como no.
• X11Forwarding yes/no:
  • Controla se o encaminhamento de display X11 (usado para rodar aplicações gráficas remotas) é permitido.
  • O padrão é no em muitas configurações modernas, mas pode ser yes em outras.
  • O encaminhamento X11 tem implicações de segurança (pode permitir que o servidor acesse seu display local). Se não for necessário, defina como no.

Opcional: Confinamento de Usuários com ChrootDirectory

Esta é uma diretiva mais avançada usada para restringir severamente o ambiente de um usuário após o login.

• ChrootDirectory /caminho/para/diretorio_chroot:
  • Quando um usuário faz login, seu diretório raiz (/) é alterado para o diretório especificado.
  • O usuário fica “preso” dentro desse diretório e não pode ver ou acessar arquivos fora dele.
  • Muito útil para restringir usuários que só precisam acessar uma área específica do sistema (ex: usuários SFTP que só podem fazer upload/download em um diretório específico).
  • Requer configuração cuidadosa: O diretório chroot e todos os seus componentes (incluindo quaisquer bibliotecas ou comandos necessários para o usuário) devem pertencer ao root e não podem ter permissão de escrita para outros usuários. Configurar um ambiente chroot funcional pode ser complexo.
  • Geralmente usado em conjunto com ForceCommand internal-sftp para criar usuários apenas SFTP.

Conclusão

O arquivo /etc/ssh/sshd_config é o painel de controle do seu servidor SSH. Ao ajustar suas diretivas, você pode ir muito além da configuração padrão, implementando medidas de segurança essenciais como desabilitar o login de root e a autenticação por senha, controlando finamente quem pode acessar o servidor, otimizando o desempenho e a robustez das conexões, e até mesmo confinando usuários a ambientes restritos.

Lembre-se sempre de testar a sintaxe (sshd -t) antes de reiniciar ou recarregar o serviço sshd, e tenha cuidado ao fazer alterações remotamente, especialmente aquelas relacionadas à autenticação, para não se trancar fora do sistema.

No próximo tutorial, voltaremos ao lado do cliente e exploraremos como simplificar e otimizar nossas conexões usando o arquivo de configuração do cliente SSH: ~/.ssh/config.