Executado pelo Administrador

A Execução do Servidor SSH pelo Administrador é o processo de inicialização, configuração e manutenção do daemon sshd no sistema hospedeiro. Em ambientes Unix-like, o servidor SSH opera como um componente de infraestrutura de "baixa latência e alta confiança", exigindo que o administrador do sistema tenha domínio pleno sobre como o serviço é instanciado, quais permissões de arquivo são mandatórias e como as chaves de identidade do servidor são geradas e protegidas. A correta execução do servidor é o que garante que o acesso administrativo permaneça disponível mesmo após reinicializações do sistema ou atualizações de segurança.

1. Localização e Propriedade do Binário sshd

O binário do servidor SSH (geralmente fixado em /usr/sbin/sshd) é um executável de alta sensibilidade técnica:

• Propriedade: Deve pertencer exclusivamente ao usuário root e possuir permissões de execução restritas (-rwxr-xr-x, modo 755).
• Bibliotecas de Ligação: O sshd depende de bibliotecas criptográficas críticas (como a OpenSSL ou LibreSSL). Uma atualização nestas bibliotecas exige a reinicialização imediata do daemon para que novos patches de segurança entrem em vigor.
• Capabilities Linux: O sshd requer CAP_NET_BIND_SERVICE (porta 22 < 1024) e CAP_SETUID/CAP_SETGID para troca de contexto de usuário após autenticação. Em sistemas hardening, pode operar via Ambient Capabilities em vez de setuid root.

Auditoria de Integridade do Binário

# Verificar permissões e propriedade
ls -l /usr/sbin/sshd
# Saída esperada: -rwxr-xr-x 1 root root 870K Feb 10 2024 /usr/sbin/sshd

# Verificar bibliotecas dinâmicas vinculadas
ldd /usr/sbin/sshd | grep -E 'libcrypto|libz'

# Verificar hash SHA256 contra pacote instalado
dpkg -V openssh-server   # Debian/Ubuntu
rpm -V openssh-server    # RHEL/CentOS

2. Sistemas de Init e Ciclo de Vida do Serviço (Systemd)

Na maioria das distribuições Linux modernas, o ciclo de vida do SSH é gerenciado pelo systemd:

• Unidade ssh.service ou sshd.service: Define as dependências de rede e sistema para que o serviço suba automaticamente no boot. Inclui diretivas como After=network.target e Wants=sshd-keygen.target.
• Recarregamento Suave (Reload): Ao contrário de um "Restart" seco que pode derrubar conexões ativas, o comando systemctl reload sshd envia um sinal SIGHUP ao processo mestre. Isto faz com que o sshd releia os arquivos de configuração sem encerrar os processos filhos que gerenciam sessões de usuários logados naquele momento.
• Socket Activation: Algumas distribuições (Fedora, RHEL 9+) usam sshd.socket com Accept=no no sshd_config, permitindo que o systemd escute na porta 22 e instancie sshd por demanda, economizando RAM em idle.

Comandos Essenciais de Ciclo de Vida

# Iniciar e habilitar no boot
sudo systemctl enable --now ssh

# Status detalhado com PID mestre
systemctl status ssh
ps -ef | grep -E 'sshd:|/usr/sbin/sshd'

# Recarregar configuração sem derrubar sessões ativas
sudo systemctl reload ssh

# Reiniciar (derruba conexões ativas — uso emergencial)
sudo systemctl restart ssh

3. Comandos de Manutenção e Teste de Configuração

Um dos erros mais graves que um administrador pode cometer é editar o arquivo /etc/ssh/sshd_config com erros de sintaxe e reiniciar o serviço, o que pode causar o travamento do daemon e a perda total de acesso remoto à máquina.

• Teste de Sintaxe (sshd -t): Antes de qualquer reinício, o administrador deve executar este comando. Ele valida a integridade do arquivo de configuração e as permissões de todas as chaves de host, retornando erros antes de comprometer o serviço ativo.
• Teste Estendido (sshd -T): Exibe a configuração efetiva após aplicar todos os defaults e includes, útil para auditoria do que realmente está em vigor.
• Execução em Primeiro Plano (sshd -D): Útil para depuração pesada, permitindo ver os logs de conexão diretamente no terminal sem enviá-los ao syslog.
• Modo Debug Verbose (sshd -ddd): Log nível 3, exibe cada mensagem do protocolo SSH em tempo real.

Procedimento Seguro de Mudança

# 1. Fazer backup do arquivo atual
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

# 2. Testar a nova configuração
sudo sshd -t && echo "OK"

# 3. Aplicar recarga suave
sudo systemctl reload ssh

# 4. Verificar se conexões antigas continuam ativas e novas funcionam
ss -tnp | grep ':22'

4. Geração Automática e Proteção de Host Keys

Na primeira execução do servidor, o sistema deve gerar suas identidades digitais únicas através do comando ssh-keygen -A:

• Localização: As chaves (RSA, ED25519, ECDSA) residem em /etc/ssh/.
• Tipos Gerados: ssh_host_rsa_key (3072 bits, padrão OpenSSH 9+), ssh_host_ed25519_key (Curve25519), ssh_host_ecdsa_key (NIST P-256). O DSA foi removido no OpenSSH 7.0 (2015).
• Segurança Crítica: As chaves privadas (ssh_host_*_key) devem possuir permissão 600 (leitura/escrita apenas pelo root). Se as permissões estiverem abertas (ex: 644), o sshd recusará a inicialização por considerar que a identidade da máquina foi comprometida.

Tabela de Permissões Mandatórias

# Regenerar todas as host keys (pós-comprometimento)
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A

# Verificar fingerprint de cada chave
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# Saída: 256 SHA256:abc... root@hostname (ED25519)

5. Perspectiva de Cyber Security e Monitoramento Operacional

Para o analista de segurança, a forma como o administrador executa o serviço revela a maturidade da infraestrutura.

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

O administrador deve garantir que o sistema possua um usuário dedicado (geralmente chamado sshd) com diretório home em /var/run/sshd e shell desativado (/sbin/nologin). Este usuário é utilizado pelo sistema para isolar transações de rede da conta de root, mitigando ataques de escalada de privilégios através de falhas de memória no daemon. Controlado pelas diretivas UsePrivilegeSeparation (obsoleto em OpenSSH 7.5+, sempre habilitado) e PrivilegedUser.

B. Auditoria de Execução

Monitorar o horário de reinício do serviço e alterações nos arquivos de configuração através de ferramentas de AIDE ou Tripwire é vital para detectar se um atacante com privilégios de root alterou os parâmetros do SSH para criar backdoors de acesso persistente.

C. CVEs Históricos de sshd

D. Logs e Detecção de Intrusão

# Monitorar tentativas de login em tempo real
sudo journalctl -u ssh -f

# Contar IPs com mais falhas
sudo journalctl -u ssh --since "24h ago" | grep 'Failed password' | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10

# Verificar sessões ativas
who
last -n 20

6. Auditoria Técnica e Diagnóstico de Execução

Validar a conformidade operacional do serviço exige o uso de ferramentas de controle de sistema:

# Verificando a integridade da configuracao antes de aplicar mudancas
sudo sshd -t && echo "Configuracao Valida"

# Verificando a configuracao efetiva (apos defaults e includes)
sudo sshd -T | grep -iE '^(permitrootlogin|passwordauthentication|maxauthtries|port|listenaddress)'

# Monitorando o estado da unidade no systemd
systemctl is-active sshd
systemctl is-enabled sshd

# Verificando se o binario foi alterado recentemente (Auditoria de arquivo)
stat /usr/sbin/sshd

# Verificando sockets em escuta
ss -tlnp | grep :22

# Testando conexão local sem fechar canal
ssh -v localhost

7. Resumo Técnico

8. Conclusão

A Execução do Servidor SSH é o ato de gerir a chave-mestra da infraestrutura. De um binário bem protegido e de arquivos de configuração testados depende a resiliência de todo o parque tecnológico de uma empresa. Dominar os sinais de recarregamento (SIGHUP via systemctl reload), utilizar sempre os testes de sintaxe (sshd -t e -T) e proteger as Host Keys do servidor — com permissões 600 root:root e rotação documentada após incidentes — são práticas que garantem que o acesso administrativo permaneça disponível mesmo após reinicializações do sistema ou atualizações de segurança. A maturidade operacional do administrador se mede pela capacidade de aplicar mudanças em produção sem jamais derrubar sessões ativas de usuários legítimos.