Hardening SSH: Como Restringir Acesso com AllowUsers e Match Group

O protocolo SSH (Secure Shell) é a espinha dorsal da administração remota de servidores Linux na maioria dos ambientes corporativos e de infraestrutura cloud. No entanto, a configuração padrão do serviço sshd, focada na usabilidade, muitas vezes expõe o servidor a vetores de ataque comuns, como força bruta de senhas e tentativas de exploração de vulnerabilidades em contas de sistema desatualizadas. O hardening SSH não se trata apenas de trocar portas ou usar chaves complexas; ele envolve a aplicação do princípio do menor privilégio na camada de transporte.

Neste tutorial técnico, abordaremos duas das diretivas mais poderosas e frequentemente mal configuradas no arquivo sshd_config: AllowUsers e Match Group. Juntas, elas permitem criar uma política de acesso granular, onde apenas usuários específicos podem iniciar sessões via SSH, e grupos distintos têm permissões de execução e autenticação diferenciadas. Este guia é destinado a sysadmins que buscam elevar o nível de segurança dos seus servidores Linux.

1. Entendendo o Arquivo sshd_config

O arquivo de configuração principal do servidor SSH em distribuições baseadas em Debian, Ubuntu e CentOS/RHEL geralmente está localizado em /etc/ssh/sshd_config. Antes de aplicar qualquer mudança crítica, é fundamental entender a estrutura deste arquivo. Ele contém diretivas que controlam desde a porta de escuta até a criptografia utilizada.

O processo de hardening exige que você edite este arquivo como root ou com privilégios equivalentes via sudo. Lembre-se sempre: uma configuração incorreta pode impedir seu acesso futuro ao servidor. Por isso, mantenha uma sessão ativa (como um terminal aberto ou um console da cloud provider) enquanto testa as novas configurações.

Abaixo, listamos as variáveis que serão manipuladas neste tutorial:

• AllowUsers: Uma lista whitelist de usuários que têm permissão para fazer login via SSH. Se esta diretiva estiver presente, apenas os usuários listados poderão se autenticar.
• Match Group: Um bloco condicional que aplica configurações específicas a todos os membros de um grupo do sistema Linux quando eles se conectam via SSH.

2. Preparação do Ambiente e Backups

A primeira etapa de qualquer mudança em infraestrutura é a preservação do estado atual. Vamos criar um backup da configuração original para permitir o rollback imediato em caso de falhas.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Agora, vamos garantir que os usuários e grupos necessários existam no sistema. Para este exemplo, criaremos dois cenários distintos:

1. Um usuário administrador dedicado chamado admin_root.
2. Um grupo de desenvolvedores chamado devs com permissões limitadas.

Crie o grupo e os usuários se eles ainda não existirem:

sudo groupadd devs
sudo useradd -m -s /bin/bash -G devs dev_user1
sudo useradd -m -s /bin/bash admin_root

Defina senhas fortes ou configure chaves SSH para esses usuários imediatamente. Sem acesso autenticado prévio, você não conseguirá testar as novas regras.

3. Restringindo Acesso com AllowUsers

A diretiva AllowUsers é a forma mais direta de implementar uma lista de permissão (whitelist). Ela aceita nomes de usuário e, opcionalmente, padrões de host ou IP no formato user@host.

Passo 3.1: Definindo a Lista Branca

Abra o arquivo de configuração com seu editor de texto favorito (nano, vim, etc.).

sudo nano /etc/ssh/sshd_config

Localize a linha que contém #AllowUsers. Note que ela está comentada por padrão. Remova o símbolo de hashtag (#) para ativar a diretiva e adicione os usuários autorizados.

AllowUsers admin_root [email protected]/24

Neste exemplo:

• admin_root pode se conectar de qualquer origem (desde que a autenticação seja bem-sucedida).
• dev_user1 só pode se conectar se estiver acessando o servidor a partir de um IP na sub-rede 192.168.1.0/24.

Se você não especificar o host, o SSH verificará apenas o nome de usuário. A inclusão do host/IP adiciona uma camada extra de segurança baseada em rede.

Passo 3.2: Desabilitando o Login de Root Direto

Embora AllowUsers já restrinja quem pode logar, é uma prática recomendada de hardening desativar explicitamente o login direto como root para manter a auditoria precisa de quem realizou as ações. Vamos garantir que esta opção esteja ativa:

PermitRootLogin no

Isso força os administradores a logarem com suas contas pessoais e elevarem privilégios via sudo, criando um log claro de atividades privilegiadas.

4. Implementando Match Group para Controle Granular

Muitas vezes, não basta apenas permitir ou negar o acesso. Você pode querer que certos grupos tenham comportamentos diferentes dentro do servidor SSH. É aqui que o Match Group brilha.

Suponha que você queira que os membros do grupo devs possam fazer login, mas não possam usar encaminhamento de porta (port forwarding) ou executar comandos arbitrários via SFTP/SCP se não estiverem em um ambiente controlado. Ou talvez você queira forçar a autenticação por chave apenas para esse grupo.

Passo 4.1: Estrutura do Bloco Match

No final do arquivo sshd_config, adicione o seguinte bloco:

# Configurações específicas para o grupo devs
Match Group devs
    PermitTTY no
    AllowTcpForwarding no
    X11Forwarding no
    PasswordAuthentication no

Vamos analisar cada diretiva dentro deste bloco:

• PermitTTY no: Impede a alocação de um pseudo-terminal. Isso é útil para scripts automatizados ou SFTP, mas pode impedir sessões interativas se não configurado corretamente com chaves.
• AllowTcpForwarding no: Desativa o encaminhamento TCP (tunelamento). Isso previne que usuários usem o SSH como um proxy SOCKS ou para tunelar conexões internas, reduzindo a superfície de ataque lateral.
• X11Forwarding no: Desativa o encaminhamento X11. Em servidores modernos, isso é raramente necessário e representa um risco de segurança se comprometido.
• PasswordAuthentication no: Obriga usuários do grupo devs a usar autenticação por chave SSH. Isso elimina completamente o risco de ataques de força bruta contra essa conta específica.

É crucial notar que as diretivas dentro de um bloco Match substituem ou sobreescrevem as configurações globais definidas acima. Se você definir PasswordAuthentication yes globalmente, o bloco Match Group devs overriderá isso para no.

5. Sintaxe Avançada e Considerações de Segurança

O sshd_config permite combinações complexas. Você pode usar múltiplos blocos Match. O OpenSSH processa o arquivo linha por linha e aplica a primeira correspondência encontrada para as diretivas subsequentes.

Exemplo de Hierarquia de Match

# Regra Global
PasswordAuthentication yes

# Regra Específica para Grupo Admins
Match Group admins
    PasswordAuthentication no
    PermitRootLogin prohibit-password

# Regra Específica para Usuário Convidado
Match User guest
    ForceCommand /usr/bin/rssh
    AllowTcpForwarding no

Neste cenário, o usuário guest terá suas configurações aplicadas porque a correspondência é feita na ordem. Se você inverter a ordem, as regras globais podem prevalecer dependendo de como as diretivas são definidas (algumas são "primeiro vence", outras "último vence"). Para evitar confusão, mantenha as regras mais específicas no final do arquivo.

Validação de Sintaxe

Antes de reiniciar o serviço, é obrigatório validar a sintaxe. O sshd possui uma flag de teste que verifica erros sem aplicar as mudanças.

sudo sshd -t

Se o comando retornar silêncio, a sintaxe está correta. Se houver erros, ele exibirá a linha e a descrição do erro. Corrija-os antes de prosseguir. Um erro comum é digitar incorretamente o nome do grupo ou usuário, o que resultará em ninguém conseguindo logar.

6. Aplicando as Mudanças

Com a configuração validada, precisamos recarregar o serviço SSH para que as novas regras entrem em vigor. Em sistemas modernos com systemd:

sudo systemctl reload sshd

Use reload em vez de restart. O reload mantém conexões existentes abertas enquanto aplica a nova configuração às novas conexões. Isso minimiza o risco de desconexão abrupta durante o horário comercial.

7. Testes de Conexão e Validação

Agora vem a parte mais crítica: testar se as restrições estão funcionando como esperado. Faça isso de uma máquina cliente diferente da qual você está editando o servidor.

Teste 1: Usuário Permitido

ssh admin_root@seu_servidor

Este usuário deve conseguir logar normalmente (respeitando as regras de senha/chave definidas globalmente).

Teste 2: Usuário Bloqueado por AllowUsers

ssh usuario_nao_listado@seu_servidor

A conexão deve ser recusada imediatamente ou negada após a autenticação, com uma mensagem indicando que o acesso é negado. Isso confirma que a whitelist está ativa.

Teste 3: Validação do Match Group

ssh dev_user1@seu_servidor

Se você tentar fazer login com senha, deve ser rejeitado (pois definimos PasswordAuthentication no para o grupo devs). Tente conectar usando sua chave SSH. Se a conexão for estabelecida, verifique se as restrições estão ativas:

# Dentro da sessão do dev_user1
ssh -L 8080:localhost:80 dev_user1@seu_servidor

O encaminhamento de porta deve falhar ou ser ignorado, dependendo da implementação exata. Você pode verificar as configurações ativas usando:

ssh -v dev_user1@seu_servidor 2>&1 | grep -i "match"

A saída verbose mostrará quais diretivas foram aplicadas durante a negociação do handshake.

8. Boas Práticas Adicionais de Hardening

Ao implementar AllowUsers e Match Group, considere complementar sua estratégia com outras medidas:

1. FalureLockout: Instale o fail2ban ou configure PAM para bloquear IPs após várias tentativas falhas de login.
2. Protocolo SSH2: Certifique-se de que apenas a versão 2 do protocolo esteja habilitada (Protocol 2), embora em versões modernas do OpenSSH, a versão 1 seja removida por padrão.
3. Criptografia Forte: Remita algoritmos fracos como ssh-rsa (SHA-1) e prefira ecdsa ou ed25519.

Conclusão

O hardening de servidores Linux não é um evento único, mas um processo contínuo. O uso correto de AllowUsers elimina a necessidade de gerenciar permissões complexas em nível de sistema operacional para o serviço SSH, centralizando o controle na camada de rede. Já o Match Group oferece a flexibilidade necessária para adaptar o comportamento do daemon às necessidades específicas de diferentes equipes (devs, ops, auditores).

Ao seguir este tutorial, você estabeleceu uma base sólida de segurança que impede acessos não autorizados e restringe funcionalidades perigosas para usuários menos privilegiados. Lembre-se de revisar suas configurações periodicamente e remover contas de usuários que não estão mais ativos na organização.

Para manter seus servidores seguros, documente todas as alterações no sshd_config e utilize ferramentas de gestão de configuração (como Ansible ou Puppet) para garantir consistência em larga escala. A segurança é responsabilidade de todos os envolvidos na infraestrutura, e o domínio dessas configurações é um diferencial essencial para qualquer sysadmin profissional.