01 - Servidor

No contexto do Modelo Cliente-Servidor do SSH, o Servidor (tecnicamente conhecido como o daemon sshd) é o componente estático e de alta autoridade que reside na máquina remota. Sua função fundamental é atuar como um guardião do sistema, aguardando conexões de rede, validando rigorosamente a identidade de quem solicita acesso e gerenciando os recursos locais alocados para as sessões autorizadas.

1. O Papel do Daemon sshd

O servidor SSH opera como um serviço de sistema (daemon) executado em segundo plano, geralmente iniciado junto com a inicialização do sistema operacional através de gerenciadores como o systemd no Linux, launchd no macOS ou Service Control Manager no Windows.

• Estado de Escuta (Listening): O servidor abre um socket de rede e fica monitorando constantemente uma porta específica — por padrão, a porta TCP 22 — aguardando pacotes de inicialização de conexão (SYN). O processo mestre é tipicamente um accept() em loop que bifurca a cada nova requisição.
• Isolamento de Privilégios (Privilege Separation): Por segurança, o processo mestre do sshd roda como root para poder ler arquivos protegidos (como hashes de senhas e chaves privadas do host). No entanto, ao aceitar uma conexão, ele spawna (bifurca) processos filhos com privilégios reduzidos para tratar a comunicação de cada usuário, mitigando o risco de falhas de segurança comprometerem todo o sistema. Implementado oficialmente desde o OpenSSH 3.3 (2002).
• RFC de Referência: RFC 4250 a RFC 4256 cobrem especificamente o comportamento do servidor SSH.

2. Responsabilidades Principais do Servidor

O servidor é o executor de mais da metade das regras de segurança do protocolo SSH durante o ciclo de vida de uma conexão:

1. Apresentação da Host Key: No início do handshake, o servidor apresenta sua chave pública e assina digitalmente os dados para provar ao cliente que ele é o servidor legítimo, prevenindo ataques de Man-in-the-Middle.
2. Imposição de Políticas: O servidor dita quais métodos de criptografia e integridade (cifras simétricas, MACs, KEX) serão aceitos, rejeitando conexões de clientes obsoletos ou inseguros. A negociação é regida pela seção 7.1 da RFC 4253.
3. Processamento da Autenticação: É o servidor que valida se a senha fornecida bate com o sistema (via PAM) ou se a chave pública enviada pelo cliente consta no arquivo authorized_keys do usuário alvo.
4. Criação do Ambiente (Shell/PTY): Após aprovar o acesso, o servidor aloca um Pseudo-Terminal (PTY) e inicializa o shell padrão do usuário (como o /bin/bash).
5. Aplicação de Cotas e Limites: Impõe restrições como MaxSessions, MaxStartups e LoginGraceTime para prevenir abusos de recursos e ataques de força bruta.

3. Configuração e Hardening (sshd_config)

O comportamento e o nível de segurança do componente Servidor são controlados centralmente através do arquivo de configuração /etc/ssh/sshd_config. É neste arquivo que administradores aplicam técnicas de endurecimento de sistema (Hardening):

• Alteração de Porta: Mudar a diretiva Port 22 para uma porta alta (ex: Port 2222) para evitar ataques automatizados de bots na internet.
• Restrição de Acesso: Usar AllowUsers ou AllowGroups para limitar quais contas podem de fato solicitar uma sessão.
• Desativação de Métodos Fracos: Configurar explicitamente quais cifras o servidor aceitará, removendo algoritmos antigos como SHA-1, 3DES ou CBC. Exemplo: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com.
• Desativação de Login Root: PermitRootLogin no ou PermitRootLogin prohibit-password para forçar uso de chaves quando o acesso administrativo direto for inevitável.
• Timeout de Sessão: ClientAliveInterval 300 e ClientAliveCountMax 2 para encerrar sessões inativas em até 10 minutos.
• Banner Legal: Banner /etc/issue.net para exibir aviso legal antes da autenticação.

4. Ciclo de Vida de uma Resposta do Servidor

Quando uma requisição chega, o servidor segue um fluxo rígido:

[Escuta na Porta 22] ──> [Recebe TCP SYN] ──> [Propõe Cifras/Troca KEX]
                                                       │
[Libera Shell/Canal] <── [Sucesso no PAM] <── [Valida Credencial (MFA/Chave)]

Em detalhe técnico, o fluxo real percorre as seguintes etapas:

1. Aceitação TCP: O sshd aceita a conexão e faz fork() para um processo filho.
2. Version String: Servidor envia SSH-2.0-OpenSSH_9.6 como banner de identificação.
3. KEXINIT: Servidor envia sua lista de algoritmos suportados (cifras, MACs, KEX, compressão).
4. Troca de Chaves (KEX): Participa do Diffie-Hellman e assina o hash de troca com sua Host Key.
5. New Keys: Servidor sinaliza ativação da cifra simétrica derivada do segredo compartilhado.
6. Authentication: Processa tentativas de login (senha, pubkey, keyboard-interactive, hostbased).
7. Channel Open: Aloca canal lógico e PTY para a sessão do usuário.

Se o cliente falhar nas tentativas de autenticação (MaxAuthTries excedido) ou enviar pacotes malformados que quebrem a integridade do protocolo, o servidor derruba sumariamente o socket TCP e registra o evento nos logs de auditoria do sistema (como /var/log/auth.log ou journalctl), permitindo que ferramentas de defesa ativa como fail2ban ou denyhosts tomem providências contra o endereço IP de origem.

5. Host Keys do Servidor

Cada servidor SSH mantém um conjunto de Host Keys em /etc/ssh/, geradas durante a instalação do pacote. Essas chaves são a identidade criptográfica da máquina:

Perder a Host Key obriga todos os clientes a reconfirmar o fingerprint, gerando alertas de segurança. Por isso, as Host Keys devem ser incluídas em rotinas de backup junto com a configuração do servidor.

6. Subsistemas Suportados

O servidor sshd não se limita a terminais interativos. Ele implementa subsistemas definidos na RFC 4254:

• SFTP (Subsystem sftp-server): Transferência de arquivos criptografada, alternativa moderna ao FTP.
• Execução Remota (exec): Roda comandos únicos sem alocação de PTY.
• Port Forwarding: Encaminhamento de portas locais (-L), remotas (-R) e dinâmico (-D, SOCKS proxy).
• Agent Forwarding: Encaminha o socket do ssh-agent do cliente para o servidor.

7. Monitoramento e Diagnóstico

# Verifica se o sshd está escutando
sudo ss -tlnp | grep :22

# Testa a configuração antes de reiniciar
sudo sshd -t

# Depura um único processo de conexão
sudo /usr/sbin/sshd -ddd -p 2222

# Lista conexões ativas
sudo ss -tnp | grep ssh

9. Comparação com Outros Daemon de Acesso Remoto

10. Conclusão

O Servidor SSH é mais do que um daemon de acesso remoto: ele é o guardião criptográfico da infraestrutura. Sua configuração reflete diretamente a postura de segurança da organização. Compreender o fluxo de privilegio separado, o ciclo de vida das conexões e as opções de hardening permite construir sistemas resistentes a ataques automatizados e a invasores determinados, mantendo a integridade das operações administrativas em larga escala. A substituição de protocolos legados como Telnet e RSH por SSH não é apenas uma modernização técnica, mas uma obrigação regulatória em ambientes sujeitos a PCI-DSS, ISO 27001 e HIPAA.