05 - Camada de Conexão

A Camada de Conexão do SSH, padronizada na RFC 4254, é o componente responsável por gerenciar a multiplexação de múltiplos canais lógicos sobre uma única conexão física e segura. Após a Camada de Transporte ter criado o túnel cifrado e a Camada de Autenticação ter validado o usuário, a Camada de Conexão permite que ocorram diversas atividades simultâneas — como a abertura de um shell interativo, a execução de comandos remotos, a transferência de arquivos e o tunelamento de tráfego de rede — sem a necessidade de abrir novas conexões TCP e handshakes custosos.

1. Multiplexação de Canais Lógicos

O SSH trata cada canal como uma entidade independente dentro do túnel. Esse conceito, análogo ao de fluxos em SCTP ou de virtual circuits em X.25, permite que múltiplas conversações paralelas coexistam sobre o mesmo socket TCP.

Identificação de Canal

• Cada lado (cliente e servidor) atribui um número único aos canais que abre.
• O número do canal é local — o cliente pode chamar seu canal de "0", e o servidor pode ter seu próprio canal "0" sem conflito.
• Permite que os pacotes de dados de um "Shell" não se misturem com os pacotes de um "SFTP", mesmo trafegando sobre o mesmo túnel cifrado.

Tipos de Mensagem Definidos na RFC 4254

Janelamento (Flow Control)

O SSH implementa seu próprio mecanismo de controle de fluxo em cada canal, análogo à sliding window do TCP. Isso garante que:

• Um processo que gera dados massivos (como uma transferência de 10 GB via SFTP) não "atropele" o buffer de recepção da outra ponta.
• O shell permaneça responsivo mesmo durante uma transferência pesada de arquivos no mesmo túnel.
• Cada canal tenha sua própria janela (initial window size), permitindo otimizações por tipo de uso.

2. Tipos de Canais Suportados

A Camada de Conexão define classes de uso baseadas na necessidade do administrador.

Session (Sessão)

O tipo de canal mais comum. É usado para:

• Shell interativo: Abre um terminal remoto (ex: ssh user@host).
• Execução de comando único: ssh user@host "uname -a".
• Subsistema: Invoca subsistemas como SFTP (subsystem sftp).

Ação: O canal aloca um PTY (Pseudo-Terminal) para que as teclas digitadas pelo usuário sejam refletidas no servidor remoto. A alocação de PTY é controlada por mensagens SSH_MSG_CHANNEL_REQUEST com tipo pty-req.

Direct-tcpip (Local Port Forwarding)

Transforma o SSH em um proxy potente:

• O cliente abre uma porta local e o servidor encaminha o tráfego desta porta para um destino na rede interna do servidor.
• Exemplo típico: ssh -L 8080:intranet:80 user@jumphost
• Utilizado para acessar serviços internos da empresa (intranet, dashboards administrativos) através de um bastion host seguro.

Forwarded-tcpip (Remote Port Forwarding)

• O servidor abre uma porta e o tráfego é encaminhado de volta para o cliente.
• Exemplo: ssh -R 9090:localhost:22 user@publico expõe o SSH local do cliente para um servidor público (útil para suporte reverso).
• Base do serviço comercial ngrok e Tailscale Funnel.

X11 Forwarding

Permite que aplicações gráficas rodando no servidor enviem seu tráfego X Window para o cliente. Embora menos usado hoje em dia (devido ao crescimento de interfaces web), ainda é essencial em ambientes de desenvolvimento Unix clássico.

Agent Forwarding

Permite que o cliente encaminhe seu ssh-agent para o servidor, de modo que o servidor possa usar as chaves do cliente para conexões subsequentes em cadeia (ssh -A).

3. Funcionamento Interno de um Canal Session

Quando um usuário executa ssh user@host, ocorre a seguinte sequência na camada de conexão:

1. SSH_MSG_CHANNEL_OPEN (type=session) — Cliente solicita abertura de canal.
2. SSH_MSG_CHANNEL_OPEN_CONFIRMATION — Servidor confirma e devolve recipient_channel.
3. SSH_MSG_CHANNEL_REQUEST (pty-req) — Cliente solicita alocação de PTY (se -t).
4. SSH_MSG_CHANNEL_REQUEST (shell) — Cliente solicita início de shell interativo.
5. SSH_MSG_CHANNEL_DATA — Troca bidirecional de dados do shell.
6. SSH_MSG_CHANNEL_EOF — Quando o usuário digita exit ou pressiona Ctrl+D.
7. SSH_MSG_CHANNEL_CLOSE — Finalização completa do canal.
8. A conexão TCP subjacente é fechada se não houver outros canais ativos.

4. Perspectiva de Segurança e Tunelamento

Para o analista de segurança da informação, a Camada de Conexão é o principal vetor para a evasão de firewalls e ataques de movimento lateral.

O Perigo do Tunelamento SSH (SSH Tunneling)

Através do redirecionamento de portas, um usuário pode "saltar" proteções de rede corporativa.

• O Ataque: Um usuário pode mapear a porta local 3306 (MySQL) para o servidor de banco de dados interno da empresa através do servidor SSH. Isso torna o tráfego de banco de dados invisível para firewalls de inspeção de pacotes, pois ele viaja cifrado dentro das mensagens SSH.
• Exfiltração de Dados: Um atacante que já comprometeu uma máquina interna pode usar ssh -R para criar um túnel reverso que extrai dados através do firewall de borda, driblando regras de DLP (Data Loss Prevention).

Hardening Recomendado

Administradores devem restringir o uso de tunelamento para usuários que não precisam desta funcionalidade, reduzindo a superfície de ataque para possíveis pivôs na rede. Diretivas no /etc/ssh/sshd_config:

X11 Forwarding e Riscos de Keylogging

Permite que o servidor envie o tráfego gráfico para o cliente, permitindo a execução de interfaces de janelas remotas. É um recurso poderoso, mas que carrega riscos de interceptação de eventos de teclado (Keylogging) se o servidor for comprometido — o servidor pode gravar todas as teclas antes mesmo de enviá-las ao cliente.

5. Multiplexação de Conexão com ControlMaster

O OpenSSH oferece recurso de reutilização de conexão pré-existente para eliminar a latência de novas conexões SSH:

# Em ~/.ssh/config
Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

Com essa configuração, a primeira conexão SSH autentica normalmente e cria um socket Unix em ~/.ssh/cm-user@host:22. Conexões subsequentes ao mesmo host reutilizam esse túnel, poupando handshake TCP e KEX. Isso reduz drasticamente o tempo de setup para scripts de automação Ansible que abrem dezenas de sessões SSH paralelas.

6. Auditoria Técnica e Diagnóstico de Canais

Monitorar o tráfego de canais é fundamental para identificar usos anômalos da infraestrutura:

# Verificando se o servidor permite tunelamento (auditoria de configuracao)
sudo sshd -T | grep -E "AllowTcpForwarding|AllowAgentForwarding|X11Forwarding|PermitTunnel"

# Monitorando conexoes Multiplexadas no lado do cliente
# O uso de Sockets de controle permite abrir novas sessoes sem novo login
ssh -O check -S /tmp/meu-sock user@host

# Listando processos filhos do sshd (cada canal session gera um processo)
ps -ef | grep -E "sshd:.*@pts|sshd:.*notty"

# Auditando conexoes SSH ativas e seus estados TCP
ss -tnp state established '( sport = :22 or dport = :22 )'

# Verificando portas forwardadas localmente pelo cliente (lsof)
lsof -i -P | grep ssh | grep LISTEN

# Detectando uso de ControlMaster aberto
ls -la ~/.ssh/cm-*

7. Casos de Uso Comuns em Ambientes Corporativos

8. Conclusão

A Camada de Conexão é o que torna o SSH uma ferramenta versátil e indispensável, indo muito além de um simples terminal remoto. Sua capacidade de orquestrar múltiplos fluxos de dados, shells e túneis sobre um único ponto de contato simplifica a gerência de rede e reduz drasticamente o overhead de conexão. Compreender a mecânica da multiplexação, controlar as permissões de encaminhamento de portas, e auditar a gestão de canais são fundamentais para garantir que a infraestrutura SSH seja não apenas um terminal remoto, mas um túnel de integração potente, seguro e auditável em ambientes de nuvem híbrida, automação de rede (Netmiko, Ansible, NAPALM) e arquiteturas zero-trust modernas.