Secure Shell (SSH)

O Secure Shell (SSH) é o protocolo da camada de aplicação que se tornou o padrão global para acesso remoto seguro a sistemas computacionais. Criado originalmente em 1995 por Tatu Ylönen na Universidade de Tecnologia de Helsinque (Finlândia), como resposta direta a um ataque de sniffing de senhas na rede universitária, o SSH evoluiu para se tornar um pilar crítico da administração de infraestrutura moderna. Sua missão técnica é substituir protocolos legados inseguros (Telnet, rsh, rlogin, rcp, FTP), provendo um túnel criptografado persistente onde a confidencialidade, a integridade e a autenticidade são garantias arquiteturais inegociáveis, padronizadas nas RFCs 4250 a 4256.

1. Contexto Histórico

Antes do SSH, a administração remota em Unix era feita pela família de protocolos Berkeley r-commands (rsh, rlogin, rcp), baseada em autenticação por IP confiado (.rhosts) e que transmitia todo o conteúdo — incluindo senhas — em texto claro pela rede. Com a popularização da internet na década de 1990 e o aumento de sniffers como tcpdump e Ethereal, tornou-se urgente um protocolo que protegesse a comunicação administrativa.

Linha do Tempo do SSH

RFCs de Referência

2. A Transição SSH-1 vs SSH-2

O protocolo passou por uma evolução fundamental para corrigir falhas de design iniciais da versão 1, implementadas às pressas em 1995.

SSH-1 (Legado e Inseguro)

A primeira versão do protocolo, embora revolucionária, possuía falhas estruturais graves:

• Verificação de integridade fraca: HMAC-SHA1 com truncagem a 128 bits sem incorporar número de sequência no MAC, permitindo ataques de inserção de pacotes (Bellare, 2002).
• Chaves de host curtas: Limite de 1024 bits para RSA, insuficiente para padrões modernos.
• Único algoritmo KEX: Diffie-Hellman group 1 (1024 bits), vulnerável ao ataque Logjam (CVE-2015-4000).
• Sem troca de chaves rekey: A chave de sessão é fixa durante toda a conexão, expondo ao ataque de criptanálise cumulativa.
• Padding Oracle: Vulnerabilidade CBC em blowfish-cbc e aes128-cbc.

O SSH-1 deve ser totalmente desativado em ambientes modernos (Protocol 2 em sshd_config).

SSH-2 (O Padrão Atual - RFC 4251)

Uma reescrita completa que introduziu melhorias massivas em segurança e performance:

• Troca de Chaves Diffie-Hellman: Permitindo que chaves de sessão sejam geradas de forma segura mesmo em canais monitorados, com rekey automático periódico.
• Verificação de Integridade via MAC com número de sequência: Cada pacote inclui o número de sequência de 32 bits no cálculo do MAC, impedindo ataques de replay e de reordenação.
• Suporte a Novas Cifras: AES-256-GCM, ChaCha20-Poly1305, AES-256-CTR — cifras AEAD modernas com proteção contra padding oracle.
• Arquitetura em 3 camadas: Transporte (RFC 4253) + Autenticação (RFC 4252) + Conexão (RFC 4254) modulares.
• Suporte a múltiplos canais: Multiplexação de shells, SFTP, X11 e port forwarding sobre uma única conexão TCP.

3. Contraste Absoluto com Protocolos Legados

Para um profissional de TI, entender a diferença entre o SSH e seus antecessores é uma lição fundamental de higiene digital:

Qualquer intermediário na rede pode capturar uma sessão Telnet sem esforço, expondo credenciais administrativas em texto claro. No SSH, toda a comunicação, desde o primeiro byte útil após a negociação inicial, viaja cifrada. Mesmo que um atacante capture os pacotes com Wireshark, ele verá apenas um fluxo de bytes binário indecifrável sem as chaves de sessão efêmeras.

4. Funcionalidades de Gerência Além do Shell

O SSH é muito mais do que um terminal remoto; ele é uma plataforma de transporte de dados segura com múltiplas extensões padronizadas: shell interativo (ssh user@host), execução remota (ssh user@host "cmd"), transferência via SCP/SFTP (RFC 4256), sincronização rsync sobre SSH, ProxyJump (-J), tunelamento Local/Remote/Dynamic (-L/-R/-D), Agent Forwarding (-A), e uso como transporte para ferramentas de automação como Ansible e Jenkins.

# Shell interativo + ProxyJump
ssh -J bastion@jumphost target@internal
# Transferência via SCP/SFTP/rsync
scp arquivo.txt alice@servidor:/tmp/
rsync -avz --delete /local/ alice@servidor:/backup/
# Tunelamento Local (acesso a DB interno)
ssh -L 5432:db.int:5432 user@bastion
# Tunelamento Dynamic (proxy SOCKS5 cifrado)
ssh -D 1080 user@bastion
# Automação Ansible (usa SSH como transporte)
ansible all -m ping -u deploy

5. Perspectiva de Cyber Security e Monitoramento

O serviço SSH é a "Joia da Coroa" de um servidor e, por isso, é alvo de ataques incessantes 24/7 por botnets como Mirai, Mobiquis e SSHSCAN.

Ataques de Reconhecimento e Exploração (RCE)

Atacantes realizam varreduras constantes na porta 22 em busca de banners de servidores desatualizados (ex: SSH-2.0-OpenSSH_7.2p2). Vulnerabilidades históricas graves incluem: CVE-2018-15473 (User enumeration por timing, OpenSSH 7.2-7.6), CVE-2016-0777 (Roaming client info leak, OpenSSH 5.4-7.1), CVE-2017-15361 (ROCA chave RSA fraca em YubiKey 4), e CVE-2023-48795 (Terrapin Prefix Truncation, todas as versões). O profissional de segurança deve manter o servidor sempre atualizado e ocultar a versão exata no banner de conexão (DebianBanner no).

Gestão de Host Keys e o Ataque de MitM

Sempre que um servidor SSH é instalado, ele gera um par de chaves únicas (Host Keys) armazenado em /etc/ssh/ssh_host_*_key. O cliente, na primeira conexão, é alertado da fingerprint e a armazena em ~/.ssh/known_hosts (modelo TOFU - Trust On First Use). Se a chave mudar em conexão futura, o cliente exibe:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Isso indica que o servidor foi reinstalado (chave regenerada) ou que um atacante está realizando um ataque de Man-in-the-Middle para interceptar a sua senha administrativa.

Hardening Recomendado

# /etc/ssh/sshd_config - hardening CIS Level 1
Protocol 2
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowGroups ssh-users
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org

6. Auditoria Técnica e Diagnóstico

# Listar cifras, MACs, KEXs suportadas pelo cliente
ssh -Q cipher; ssh -Q mac; ssh -Q kex

# Conectando com verbosidade para ver o processo
ssh -v user@servidor.com
ssh -vvv user@servidor.com  # debug completo

# Validar configuração do sshd antes de reload
sudo sshd -t && sudo systemctl reload sshd

# Listar algoritmos efetivamente suportados pelo daemon
sshd -T | grep -E "ciphers|macs|kexalgorithms"

# Inspecionar fingerprint de host keys
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# Detectar algoritmos legados ainda suportados
nmap --script ssh2-enum-algos -p 22 servidor.com

7. Resumo Técnico

8. Conclusão

O Secure Shell é a ferramenta definitiva que permite a gestão de infraestruturas globais com a confiança de uma conexão local. Sua arquitetura inquebrável, somada à versatilidade de tunelamento e transferência de arquivos, torna-o o protocolo mais importante para a administração de servidores modernos, base de plataformas como Ansible, Git over SSH, Kubernetes API e Jenkins pipelines. Compreender a história (Ylönen, 1995), entender as falhas críticas do SSH-1, dominar a arquitetura em 3 camadas, migrar sistematicamente para cifras modernas (Ed25519, Curve25519, AES-GCM, ChaCha20-Poly1305) e aplicar hardening rigoroso (sem root direto, MFA via PAM, Whitelist via AllowGroups) são competências essenciais para garantir que o acesso permaneça soberano, íntegro e inalcançável por adversários no cenário cibernético contemporâneo.