Conexão Segura Estabelecida (Sessão SSH)

A Sessão SSH é o estado operacional que ocorre após o sucesso do "aperto de mão" (handshake) e da autenticação. Quando dizemos que uma conexão segura foi estabelecida, significa que o cliente e o servidor criaram um túnel criptográfico íntegro, onde a identidade de ambos foi verificada, uma chave de sessão simétrica única foi gerada para proteger o tráfego subsequente, e o servidor associou o túnel a um usuário específico do sistema operacional. Este estado é distinto de uma simples conexão TCP ESTABLISHED, pois envolve múltiplas camadas de estado criptográfico, contextual e de auditoria que precisam ser mantidas coerentemente em ambas as pontas.

1. O Estado de "Conexão Estabelecida"

Tecnicamente, uma conexão SSH estabelecida não é apenas um socket TCP aberto; é uma construção lógica de várias camadas de segurança que atingiram a maturidade simultânea:

Camadas Ativas no Estado Estabelecido

• Camada de Transporte (RFC 4253): Garante que a troca de chaves (KEX) foi concluída com sucesso, que o SSH_MSG_NEWKEYS foi trocado, e que o sigilo direto perfeito (Perfect Forward Secrecy) está ativo através de Diffie-Hellman efêmero.
• Camada de Autenticação (RFC 4252): Confirma que o servidor aceitou as credenciais (senha, chave pública, GSSAPI ou certificado X.509) e vinculou a sessão a um usuário específico do sistema operacional (UID/GID efetivos aplicados).
• Camada de Conexão (RFC 4254): Pronta para abrir múltiplos canais lógicos multiplexados (shell, SFTP, port forwarding, X11) sobre o mesmo túnel cifrado.
• Cifragem Ativa: A partir deste ponto, cada byte enviado pelo teclado do cliente é cifrado antes de sair para a rede e decifrado apenas dentro da memória do servidor, e vice-versa. O algoritmo negociado (ex: aes256-gcm@openssh.com) está com a chave derivada e o contador de pacotes inicializado.

Sequência de Estados até o Estabelecimento

2. Características do Túnel Estabelecido

Uma vez que a conexão está segura e ativa, ela apresenta propriedades fundamentais que a distinguem de uma conexão TCP comum:

Bidirecionalidade

Tanto o cliente quanto o servidor podem enviar dados simultaneamente de forma segura, sem lockstep. Isto é fundamental para shells interativos onde Ctrl-C precisa interromper imediatamente um comando em execução, sem esperar o fluxo de saída terminar.

Multiplexação

Uma única conexão segura estabelecida pode suportar múltiplos "canais" lógicos (ex: um shell interativo, uma transferência de arquivo via SFTP e um encaminhamento de porta rodando ao mesmo tempo no mesmo túnel). Esta multiplexação é gerenciada pela Camada de Conexão (RFC 4254), com janelamento e controle de fluxo independente por canal.

Integridade Contínua

Cada pacote possui um número de sequência de 32 bits e um código de autenticação de mensagem (MAC) calculado sobre o ciphertext. Se houver qualquer tentativa de injeção de dados no túnel (ex: ataque MITM ativo), o MAC falha e a conexão é derrubada instantaneamente com Bad packet length ou MAC error.

Perfect Forward Secrecy

Mesmo que um atacante grave toda a sessão hoje e comprometa a chave privada do servidor daqui a 5 anos, ele não conseguirá decifrar a sessão gravada, pois a chave de sessão foi derivada via Diffie-Hellman efêmera e nunca trafegou pela rede.

3. O "Welcome Message" e o Shell

O sinal visível para o usuário de que a conexão segura foi estabelecida é, geralmente, a exibição de:

1. Banner de conexão (se configurado via Banner /etc/issue.net no sshd_config).
2. MOTD (Message of the Day) exibido pelo PAM a partir de /etc/motd.
3. Last login information exibido pelo pam_lastlog (RFC compliance).
4. Shell prompt (ex: user@server:~$) indicando que o shell está pronto para receber comandos.

Recursos Alocados no Servidor

Neste estágio final de estabelecimento:

• O servidor alocou um PTY (Pseudo-Terminal) para o usuário, com tamanho e tipo de terminal ($TERM=xterm-256color) herdados do cliente.
• As variáveis de ambiente (como PATH, TERM, LANG, USER, LOGNAME, HOME) foram carregadas a partir de /etc/profile, ~/.bash_profile ou ~/.zshrc.
• O log de "Last Login" foi atualizado nos arquivos de auditoria do sistema (/var/log/auth.log em Debian/Ubuntu, /var/log/secure em RHEL/CentOS, e em journalctl -u ssh em sistemas com systemd).

4. Manutenção da Sessão (Keep-Alive)

Uma conexão estabelecida pode enfrentar problemas de inatividade (idle) que causam queda silenciosa por timeout de NAT, firewall stateful ou roteador intermediário. Para garantir que o túnel permaneça ativo através desses dispositivos, utilizam-se mensagens de controle keepalive:

Diretivas de Keep-Alive

Como essas mensagens são enviadas dentro do túnel já estabelecido, elas também são cifradas e protegidas contra manipulação, sendo indistinguíveis de tráfego de dados normal para um observador externo.

Configuração Recomendada no Cliente

# Em ~/.ssh/config
Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3
  TCPKeepAlive yes
  ControlMaster auto
  ControlPath /tmp/ssh-%r@%h:%p
  ControlPersist 10m

A diretiva ControlMaster habilita multiplexação de conexões: uma vez estabelecida a primeira sessão, sessões subsequentes para o mesmo host reutilizam o túnel existente, economizando segundos de handshake em automações Ansible e CI/CD.

5. Finalização Segura

A sessão permanece estabelecida até que uma das seguintes condições ocorra:

• O usuário execute o comando exit, logout ou pressione Ctrl-D (EOF no terminal).
• O processo cliente seja encerrado (kill, fechamento de terminal, reboot).
• O processo servidor seja encerrado (systemctl stop sshd, OOM killer, reboot).
• Ocorra uma falha de rede irrecuperável (timeout de keep-alive excedido, queda de link, rede móvel perdida).
• Ocorra uma violação de integridade (MAC mismatch, número de sequência fora de ordem), derrubando imediatamente a sessão por segurança.

Limpeza de Recursos

No encerramento, ocorrem várias etapas críticas:

1. SSH_MSG_CHANNEL_EOF e SSH_MSG_CHANNEL_CLOSE são trocados em ambos os sentidos.
2. SSH_MSG_DISCONNECT é enviado com código de razão (RFC 4254 seção 11).
3. O socket TCP é fechado normalmente com FIN/ACK.
4. As chaves de sessão temporárias (simétrica, IV, MAC keys) são imediatamente apagadas da memória RAM de ambas as máquinas via memset_explicit(3), garantindo que, mesmo que o hardware seja periciado posteriormente (ataque cold boot), os dados daquela sessão específica não possam ser recuperados.
5. O PTY é liberado de volta ao kernel.
6. O registro de auditoria é finalizado com timestamp de logout (atualizado em /var/log/wtmp e consultável via last).

6. Auditoria e Diagnóstico

# Listando sessões SSH ativas no servidor
who | grep -E "pts|tty"
ss -tnp state established '( sport = :22 )'

# Verificando quem está logado e de onde
last -n 20 -F
lastlog | grep -v "Never"

# Verificando conexões SSH em tempo real no journalctl
journalctl -u ssh -f

# Verificando criptografia efetivamente negociada em uma sessão
ssh -vv user@host 2>&1 | grep -E "cipher|MAC|kex|hostkey"

# Detectando sessões travadas/zumbis
ps aux | grep -E "sshd:.*@pts" | grep -v grep

7. Resumo Técnico

8. Conclusão

A Conexão Segura Estabelecida representa o ápice do protocolo SSH: todas as camadas (Transporte, Autenticação, Conexão) operando em harmonia, oferecendo ao administrador remoto a mesma experiência interativa de um terminal local, mas com a segurança criptográfica de uma VPN ponta a ponta. Compreender os estados intermediários do handshake, configurar adequadamente os parâmetros de keep-alive para resistir a NATs e firewalls stateful, auditar sessões ativas via who/last/journalctl e garantir a limpeza segura de chaves temporárias no encerramento são competências essenciais para operar infraestrutura SSH de missão crítica em ambientes corporativos modernos, especialmente em cenários de administração remota de longa duração como automação Ansible, tunelamento de bancos de dados e jump servers (bastion hosts) em arquiteturas zero-trust.