Entender o Secure Shell Packet Exchange

Introdução

Este documento descreve a troca de nível de pacote durante a negociação Secure Shell (SSH).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento dos conceitos básicos de segurança:

• Autenticação
• Confidencialidade
• Integridade
• Métodos de Troca de Chaves

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Protocolo SSH

O protocolo SSH é um método para o login remoto seguro de um computador para outro. Os aplicativos SSH são baseados em uma arquitetura cliente-servidor, conectando uma instância de cliente SSH com um servidor SSH.

Troca SSH

1. A primeira etapa do SSH é chamada Identification String Exchange.

 1.1. O cliente constrói um pacote e o envia ao servidor contendo:

•  Versão do protocolo SSH
•  Versão de software

Versão do protocolo do cliente e versão do software

1.2. O servidor responde com seu próprio Identification String Exchange, incluindo a versão do protocolo SSH e a versão do software.

Versão do protocolo do servidor e versão do software

2. Próxima Etapa é  Algorithm Negotiation. Nesta etapa, o Cliente e o Servidor negociam estes algoritmos:

• Troca de chaves
• Criptografia
• Código de Autenticação de Mensagem Baseado em Hash (HMAC)
• Compressão

2.1. O cliente envia uma mensagem Key Exchange Init ao servidor, especificando os algoritmos que suporta. Os algoritmos são listados em ordem de preferência.

Inicialização de Troca de Chave de Cliente

Algoritmos suportados pelo cliente

2.2. O servidor responde com sua própria mensagem Key Exchange Init, listando os algoritmos que suporta.

2.3. Uma vez que estas mensagens são trocadas em simultâneo, ambas as partes comparam as suas listas de algoritmos. Se houver uma correspondência nos algoritmos suportados por ambos os lados, eles passarão para a próxima etapa. Se não houver correspondência exata, o servidor seleciona o primeiro algoritmo na lista do cliente que ele também suporta.

Note: Se o cliente e o servidor não conseguirem chegar a um acordo sobre um algoritmo comum, a troca de chaves falhará.

Inicialização de Troca de Chave de Servidor

 Key Exchange 3. Em seguida, ambos os lados entram na fase para gerar segredo compartilhado usando a troca de chave DH e autenticar o servidor:

3.1. O cliente gera um par de chaves Public and Private, e envia a chave pública DH no pacote Diffie-Hellman Group Exchange Init. Esse par de chaves é usado para o cálculo de chave secreta.

Client Diffie-Hellman Group Exchange Init

3.2. O servidor gera seu próprio par de Public and Private kchaves. Ele usa a chave pública do cliente e seu próprio par de chaves para calcular o segredo compartilhado.

3.3. O Servidor também calcula um Hash do Exchange com estas entradas:

• Cadeia de Caracteres de Identificação do Cliente
• Cadeia de Caracteres de Identificação do Servidor
• Carga de Inicialização de Troca de Chave de Cliente 
• Carga de Inicialização de Troca de Chave do Servidor 
• Chave pública do servidor de chaves do host (par de chaves RSA)
• Chave Pública DH do Cliente
• Chave Pública DH do Servidor
• Chave Secreta Compartilhada

3.4. Depois de calcular o hash, o servidor o assina com sua chave privada RSA.

3.5. O Servidor constrói uma mensagem Diffie-Hellman Group Exchange que inclui:

•  Chave pública RSA do servidor (para ajudar o cliente a autenticar o servidor)
•  DH Chave pública do servidor (para calcular o segredo compartilhado)
•  HASH (para autenticar o servidor e provar que o servidor gerou o segredo compartilhado, pois a chave secreta faz parte do cálculo do hash)

Resposta de Troca de Grupo Diffie-Hellman do Servidor

3.6. Depois de receber a resposta Diffie-Hellman Group Exchange, o cliente calcula o hash da mesma forma e o compara com o hash recebido, descriptografando-o usando a chave pública RSA do servidor.

3.7. Antes de descriptografar o HASH recebido, o cliente deve verificar a chave pública do servidor. Essa verificação é feita por meio de um certificado digital assinado por uma CA (Autoridade de Certificação). Se o certificado não existir, cabe ao cliente decidir se aceita a chave pública do servidor.

Observação: quando você usa o SSH para fazer login em um dispositivo pela primeira vez que não usa um certificado digital, você pode encontrar um pop-up solicitando que você aceite manualmente a chave pública do servidor. Para evitar que esse pop-up seja exibido toda vez que você se conectar, você pode optar por adicionar a chave de host do servidor ao cache.

Chave Pública do Servidor

4. Como o segredo compartilhado agora é gerado, ambas as extremidades o usam para derivar essas chaves:

•  Chaves de criptografia
•  Chaves IV - São números aleatórios usados como entrada para algoritmos simétricos para aumentar a segurança.
•  Chaves de integridade

O fim da troca de chaves é sinalizado pela troca da NEW KEYS mensagem, que informa a cada parte que todas as mensagens futuras são criptografadas e protegidas usando essas novas chaves.

Chaves novas de cliente e servidor

5. A etapa final é a Solicitação de Serviço. O cliente envia um pacote de solicitação de serviço SSH ao servidor para iniciar a autenticação do usuário. O servidor responde com uma mensagem SSH Service Accept, solicitando que o cliente faça login. Essa troca ocorre através do canal seguro estabelecido.

Informações Relacionadas

• Configurar SSH nos roteadores e switches
• O protocolo de camada de transporte Secure Shell (SSH)
• Suporte técnico e downloads da Cisco