Servidor SSH (sshd)

O Servidor SSH (sshd), abreviação de SSH Daemon, é a entidade técnica que governa o acesso remoto em sistemas operacionais Unix-like e servidores corporativos. Operando como um serviço de escuta contínua, geralmente na porta TCP 22 (alterável via Port directive), o sshd é o guardião que recebe e valida as intenções de conexão de clientes externos, controlando todos os aspectos do handshake criptográfico, autenticação, autorização, execução de comandos e gerenciamento de sessões estabelecidas. Sua arquitetura é projetada para ser resiliente a falhas e resistente a ataques, utilizando modelos de isolamento de processos para garantir que a queda de uma sessão individual não comprometa a estabilidade e a segurança global do hospedeiro.

1. O Modelo de Execução: Processo Mestre e Filhos

Para gerenciar o tráfego de múltiplos administradores simultâneos, o sshd adota um modelo de Pre-Fork com separação de privilégios, distinto do Apache Prefork e do modelo event-loop do NGINX.

Processo Mestre (Master Process)

• Roda com privilégios de root (UID 0) para poder abrir a porta 22 (< 1024 requer root) e acessar os arquivos de senhas do sistema (/etc/shadow, /etc/passwd).
• Sua função é puramente de escuta (Listen) e aceitação (Accept) de novas conexões TCP.
• Quando uma nova conexão chega, o mestre realiza o fork(2) imediato para gerar um processo filho dedicado.
• Em sistemas modernos, o mestre é gerenciado pelo systemd via socket activation (systemctl status sshd ou sshd.service).

Processos de Sessão (Worker Processes)

Para cada conexão aceita, o mestre cria um novo processo filho. Este processo é responsável por gerenciar toda a criptografia, autenticação e execução de comandos para aquele usuário específico, operando de forma isolada do restante do sistema. Após a autenticação bem-sucedida, o worker faz setuid(2) para o UID do usuário alvo, abandonando os privilégios de root.

Tabela: Hierarquia de Processos

2. Separação de Privilégios (Privilege Separation)

Uma das inovações de segurança mais importantes do OpenSSH, introduzida em 2002 (versão 3.2), é a Separação de Privilégios, que divide cada conexão em dois processos com níveis de privilégio distintos.

Processo Monitor (Privileged)

• Mantém privilégios de root apenas para operações que exigem (leitura de /etc/shadow, validação de chaves, bind de portas < 1024 em port forwarding).
• Não manipula diretamente dados da rede, apenas responde a requisições do processo net via pipe UNIX.

Processo Net (Unprivileged)

• Roda com usuário sshd (UID dedicado, geralmente 74 no RHEL, 107 no Debian).
• Lida com todo o tráfego de rede bruto (potencialmente malicioso) antes e durante a autenticação.
• Se um atacante descobrir um exploit no parsing de pacotes brutos (ex: buffer overflow no KEX), ele ficará preso neste processo sem privilégios e sem acesso ao sistema de arquivos real, impedindo a escalada para root.

Configuração

# /etc/ssh/sshd_config
UsePrivilegeSeparation sandbox   # OpenSSH 7.x+ (deprecated 9.x: sempre ativo)

Desde o OpenSSH 7.5, a separação de privilégios está sempre ativa e não pode mais ser desativada, refletindo sua importância fundamental na defesa em profundidade.

3. Gestão de Autenticação e Autorização

O servidor é o juiz final da identidade do solicitante, integrando múltiplos métodos de autenticação e fontes de identidade.

Métodos de Autenticação Suportados

Fontes de Identidade Externas

• PAM (Pluggable Authentication Modules): O sshd pode se integrar ao sistema de autenticação local (Shadow), bancos de dados LDAP, Active Directory (AD), RADIUS, TACACS+ ou sistemas MFA como Duo Security e Google Authenticator para validar usuários corporativos.
• authorized_keys: O servidor gerencia o acesso via chaves públicas, verificando se a assinatura enviada pelo cliente corresponde a uma das chaves no diretório ~/.ssh/authorized_keys do usuário (ou em /etc/ssh/authorized_keys/%u para configuração centralizada).

4. Perspectiva de Cyber Security: O Hardening do Daemon

O endurecimento do sshd é frequentemente citado como a tarefa mais crítica da segurança de rede de um servidor exposto à internet.

Alteração da Porta Padrão (Security through Obscurity)

Embora não impeça ataques direcionados, mudar a porta 22 para uma porta alta (ex: 2222, 22022) reduz drasticamente o ruído e a carga de ataques automatizados de botnets (Mirai, SSHSCAN, delegated-botnet) que realizam varreduras em toda a Internet IPv4. Estudos da SANS mostram que mudar da porta 22 para 2222 reduz em ~95% o número de tentativas de login automatizadas registradas em logs.

Controle de Login e Grupos

Configurações rigorosas impedem que usuários desnecessários tenham acesso remoto:

# Whitelist de usuários autorizados
AllowUsers alice bob deploy

# Whitelist de grupos autorizados (preferido em ambientes corporativos)
AllowGroups ssh-users admins

# Bloqueio de login direto como root
PermitRootLogin prohibit-password   # Permite só via chave pública
# ou, mais rigoroso:
PermitRootLogin no                  # Força uso de usuário comum + sudo

# Bloqueio de senhas vazias
PermitEmptyPasswords no

Outras Diretivas Críticas de Hardening

5. Auditoria Técnica e Diagnóstico de Servidor

O acompanhamento da saúde do serviço exige o domínio das ferramentas de sistema e o conhecimento dos logs relevantes:

# Verificando se o daemon está escutando na porta correta
ss -tlnp | grep sshd

# Inspecionando falhas de autenticação em tempo real para detectar ataques de força bruta
journalctl -u ssh -f | grep "Failed password"

# Validando a sintaxe do arquivo de configuração principal (/etc/ssh/sshd_config)
sudo sshd -t

# Verificando versão do OpenSSH e features compiladas
sshd -V

# Listando algoritmos suportados pelo daemon (auditoria de hardening)
sshd -T | grep -E "ciphers|macs|kexalgorithms|hostkeys"

# Recarregando configuração sem derrubar sessões ativas (zero downtime)
sudo systemctl reload sshd

# Verificando usuários atualmente logados via SSH
who | grep -E "pts|tty"
last -n 20 -F

6. Resumo Técnico

7. Conclusão: O Guardião da Infraestrutura

O Servidor SSH (sshd) é o componente que transforma uma máquina isolada em um nó administrativo acessível e seguro. Sua arquitetura de isolamento de processos (privilege separation) e sua integração com esquemas de autenticação multifator (MFA via PAM, certificados X.509, chaves FIDO2) o tornam o pilar central da gerência de infraestrutura em nuvem e data centers modernos. Configurar corretamente o daemon, implementar separação de privilégios, desativar o acesso direto de root, restringir métodos de autenticação aos modernos (Ed25519, RSA-SHA2) e monitorar continuamente os logs de auditoria são competências essenciais para garantir que o servidor seja uma fortaleza inexpugnável frente aos crescentes desafios de segurança do cenário global, mantendo ao mesmo tempo a agilidade operacional que o SSH oferece a administradores, engenheiros DevOps e plataformas de automação como Ansible, Chef e SaltStack.