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.

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.

• O cliente envia uma linha de texto no formato: SSH-protoversion-softwareversion comments.

• 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.

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, detalha o que o cliente “deseja” usar para:

• Troca de chaves (Key Exchange).

• Cifras de criptografia simétrica.

• Algoritmos de integridade (MAC).

• Métodos de compressão.

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.

4. Requisição de Autenticação

Uma vez que o túnel cifrado básico foi estabelecido através da troca de chaves, o cliente envia a requisição de autenticação de usuário.

• Método de Senha: O cliente solicita ao usuário a credencial e a envia cifrada.

• Método de Chave Pública: 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: 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.

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:

• Session Channel: 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.

• Forwarding Request: Requisição para encaminhar portas locais para o servidor (Túnel SSH).

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 nesta fase incluem Connection Refused (porta fechada) ou No route to host (problemas de rede ou firewall).