A arquitetura Cliente-Servidor é o modelo estrutural dominante do protocolo SSH, permitindo que o controle remoto e a transferência de dados ocorram de forma segura em redes inseguras. Diferente de modelos Peer-to-Peer (P2P), onde as máquinas possuem funções simétricas, o SSH estabelece uma distinção clara entre a entidade que solicita o acesso e a entidade que provê o serviço e os recursos.


1. Definição dos Papéis

No ecossistema SSH, a comunicação é sempre iniciada por um dos lados, estabelecendo uma hierarquia funcional:

  • Servidor SSH (SSHD): É o hospedeiro (host) que disponibiliza o acesso. Ele executa um processo em segundo plano (o daemon sshd) que “escuta” permanentemente por conexões em uma porta específica (padrão TCP 22). Sua função é autenticar solicitantes e criar sessões de shell ou túneis de dados.

  • Cliente SSH: É a aplicação utilizada pelo usuário (como ssh no terminal Linux/macOS ou o PuTTY no Windows) para iniciar a conexão. O cliente é responsável por validar a identidade do servidor e apresentar as credenciais de acesso.


2. O Fluxo de Interação

A arquitetura dita uma sequência rigorosa de eventos para garantir que o “aperto de mão” (handshake) seja bem-sucedido:

  1. Solicitação de Conexão: O Cliente inicia um Three-Way Handshake TCP voltado para a porta 22 do Servidor.

  2. Negociação de Protocolo: Servidor e Cliente trocam versões de software e capacidades criptográficas suportadas (algoritmos de troca de chave, cifras simétricas e MACs).

  3. Troca de Chaves (KEX): Através de criptografia assimétrica, ambos geram uma chave de sessão compartilhada sem nunca enviá-la pela rede.

  4. Autenticação: O Servidor desafia o Cliente a provar sua identidade (via senha ou chave pública).

  5. Abertura de Canal: Uma vez autenticado, o Servidor cria um ambiente de execução (Shell) para o Cliente.


3. Gerenciamento de Múltiplas Sessões

Uma característica fundamental desta arquitetura é a capacidade do Servidor de gerenciar centenas de conexões de Clientes simultâneos.

  • Para cada conexão de cliente, o processo mestre sshd faz um “fork” (cria um processo filho) ou utiliza threads para isolar a sessão daquele usuário específico.

  • Isso garante que, se a sessão de um cliente falhar ou for encerrada, as demais conexões ativas no servidor não sejam afetadas.


4. Localização e Identidade

Nesta arquitetura, a confiança é bidirecional, mas os métodos de identificação diferem:

  • Identidade do Servidor: O servidor é identificado pela sua Host Key. O cliente armazena essa chave no arquivo known_hosts para garantir que está se conectando ao servidor correto em acessos futuros.

  • Identidade do Cliente: O servidor identifica o cliente através do seu nome de usuário e método de autenticação (senha ou authorized_keys).

5. Aplicação da Arquitetura (CLI e Encaminhamento)

A separação entre cliente e servidor permite funcionalidades avançadas, como o X11 Forwarding. Neste cenário, o Servidor SSH (remoto) pode encaminhar a interface gráfica de uma aplicação para que ela seja renderizada no Cliente SSH (local), utilizando o túnel seguro já estabelecido. O Servidor atua como o motor de processamento, enquanto o Cliente atua como a interface de visualização.

6. Segurança e Portabilidade

Como o software Cliente é independente do Servidor, é possível utilizar um cliente Linux para gerenciar um servidor rodando AIX, Solaris ou Windows, desde que ambos sigam as especificações do protocolo SSH-2. A arquitetura cliente-servidor isola a complexidade da rede, permitindo que o usuário interaja com o sistema remoto como se estivesse fisicamente sentado à frente dele.