Envia Requisições de Conexão

No modelo cliente-servidor do SSH, a responsabilidade de iniciar qualquer interação recai exclusivamente sobre o Cliente SSH. O envio de requisições de conexão é o estágio inicial e ativo do protocolo, onde o cliente localiza o servidor remoto e propõe o estabelecimento de um túnel seguro. Sem esta ação proativa do componente cliente, o servidor permaneceria em estado de espera (listening) indefinidamente.

1. A Natureza da Requisição de Conexão

Diferente de protocolos baseados em broadcast, o SSH exige que o cliente conheça o endereço de destino (IP ou FQDN) e a porta de serviço (padrão 22). A requisição de conexão não é um único pacote, mas uma sequência lógica de eventos que começa na camada de transporte e sobe para a camada de aplicação.

• O Gatilho: O usuário ou um script executa o binário cliente (ex: ssh usuario@servidor).
• O Socket: O sistema operacional do cliente abre um socket local e tenta estabelecer uma conexão TCP com o IP e porta alvo.
• Resolução de Endereço: Se o destino for um FQDN, o cliente primeiro consulta o DNS para obter o(s) IP(s) (priorizando AAAA em dual-stack conforme RFC 6724).
• Conexão TCP: Estabelecimento via three-way handshake (SYN → SYN-ACK → ACK), com timeout padrão de ConnectTimeout 30 no OpenSSH.

2. O Handshake de Versão (Version Exchange)

Assim que a conexão TCP é estabelecida, a primeira "requisição" real do protocolo SSH é o envio de uma string de identificação, especificada pela RFC 4253.

• O cliente envia uma linha de texto no formato: SSH-protoversion-softwareversion comments.
• Exemplo real do OpenSSH 9.6: SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.4.
• Objetivo: Informar ao servidor quais capacidades o cliente possui. Se o cliente enviar uma requisição para SSH-1.5 e o servidor for configurado para aceitar apenas SSH-2.0, a conexão é encerrada imediatamente antes mesmo de qualquer criptografia ser discutida.
• Formato Stricto: Antes da string de identificação, clientes e servidores podem trocar outras linhas ASCII terminadas em \r\n (banner), mas devem começar com SSH-. Linhas inválidas são ignoradas até um limite de 256 linhas ou 5 segundos (LoginGraceTime).

Linha do Tempo de Versões

3. Negociação de Algoritmos (KEXINIT)

Após a troca de versões, o cliente envia uma requisição contendo uma lista de algoritmos preferenciais. Este pacote, conhecido como KEXINIT (mensagem SSH_MSG_KEXINIT), detalha o que o cliente "deseja" usar para:

• Key Exchange (KEX): curve25519-sha256, ecdh-sha2-nistp256, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512.
• Cifras simétricas (cipher): chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes256-ctr.
• MAC: hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com, AEAD embutido em ChaCha20/AES-GCM.
• Compressão: none (padrão), zlib@openssh.com (delayed).

O cliente sempre envia suas opções em ordem de prioridade (do mais seguro/eficiente para o menos). O servidor compara esta lista com a sua própria e seleciona a primeira correspondência mútua (prime match wins).

Auditoria de Algoritmos Negociados

# Cliente envia suporte próprio
ssh -Q cipher        # lista todas as cifras suportadas
ssh -Q mac           # lista todos os MACs suportados
ssh -Q kex           # lista todos os KEX suportados

# Inspeção do que realmente foi negociado em uma conexão
ssh -vv usuario@servidor 2>&1 | grep -E "peer server KEX|cipher|MAC|compression"

4. Requisição de Autenticação

Uma vez que o túnel cifrado básico foi estabelecido através da troca de chaves (KEX + NEWKEYS), o cliente envia a requisição de autenticação de usuário (SSH_MSG_USERAUTH_REQUEST, RFC 4252 §5).

• Método de Senha (password): O cliente solicita ao usuário a credencial e a envia cifrada.
• Método de Chave Pública (publickey): O cliente envia uma requisição contendo sua chave pública e uma assinatura digital que prova a posse da chave privada correspondente.
• Agente SSH (ssh-agent): O cliente pode requisitar a conexão utilizando chaves armazenadas em um ssh-agent na memória, evitando que o usuário precise digitar senhas repetidamente.
• Host Based (hostbased): Autenticação delegada — o cliente prova que é um host confiável via /etc/ssh/ssh_known_hosts (raramente usado, configurado via HostbasedAuthentication yes).

Fluxo de Mensagens de Autenticação

Cliente -> SSH_MSG_SERVICE_REQUEST "ssh-userauth"        -> Servidor
Cliente <- SSH_MSG_SERVICE_ACCEPT                        <- Servidor
Cliente -> SSH_MSG_USERAUTH_REQUEST (method=none)        -> Servidor  # probe
Cliente <- SSH_MSG_USERAUTH_FAILURE (methods=publickey,  <- Servidor
                                     password,keyboard-interactive)
Cliente -> SSH_MSG_USERAUTH_REQUEST (method=publickey)   -> Servidor
Cliente <- SSH_MSG_USERAUTH_SUCCESS                      <- Servidor

5. Requisição de Canais e Serviços

Após a autenticação ser aceita, o cliente ainda precisa requisitar o que ele quer fazer no servidor. O SSH permite múltiplos canais dentro de uma única conexão (multiplexação RFC 4254):

• Session Channel (session): Requisição de um shell interativo (o uso mais comum).
• Exec Channel: Requisição para executar um comando único e sair (ex: ssh user@host "uptime").
• Subsystem Channel: Requisição para iniciar um subsistema específico, como o SFTP (subsystem=sftp em /etc/ssh/sshd_config).
• Direct TCP/IP (direct-tcpip): Port forwarding local (ssh -L 8080:intranet:80 user@gateway).
• Forwarded TCP/IP (forwarded-tcpip): Port forwarding remoto (ssh -R 8080:local:80 user@gateway).
• X11 Forwarding: Tunelamento de aplicações gráficas X11 via ssh -X.

Exemplo de Multi-canal com ControlMaster

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

Permite abrir múltiplos canais reutilizando a mesma conexão TCP, economizando o custo de novo handshake.

6. Tratamento de Timeouts e Erros

Durante o envio de requisições, o cliente monitora o tempo de resposta. Se o servidor não responder a uma requisição de conexão dentro do período de timeout, o cliente encerra o processo para evitar o consumo desnecessário de recursos locais.

Erros Comuns e Diagnóstico

Timeouts Configuráveis

# ~/.ssh/config
Host *
    ConnectTimeout 10          # TCP connect timeout
    ServerAliveInterval 30    # keep-alive request a cada 30s
    ServerAliveCountMax 3     # 3 tentativas = 90s de inatividade
    TCPKeepAlive yes           # SO_KEEPALIVE no socket

7. Resumo Técnico

8. Conclusão

O envio de requisições de conexão pelo cliente SSH é um processo multitarefa e encadeado: TCP → Version → KEXINIT → KEX → NEWKEYS → USERAUTH → CHANNEL_OPEN. Cada estágio é dependente do sucesso do anterior e falhas em qualquer ponto produzem mensagens de erro características. Dominar a leitura dessas requisições — visíveis com ssh -vv ou captura via tcpdump port 22 — é o que diferencia o administrador sênior capaz de diagnosticar problemas de rede intermediários de firewalls, NATs e proxies TLS-terminating que afetam o estabelecimento de sessões SSH.