Entender a captura wireshark para troca de chaves ssh [closed]

Question

Eu preciso entender a troca de chaves SSH, eu tentei ler o documento RFC, mas parece muito difícil de entender, então eu capturei pacotes usando wireshark, eu encontrei vários pacotes para ssh keyexchange

SSHv2 Client: Key Exchange Init
SSHv2 Server: Key Exchange Init
SSHv2 Client: Diffie-Hellman Key Exchange Init
SSHv2 Server: Diffie-Hellman Key Exchange Reply
SSHv2 Client: Diffie-Hellman GEX Init
SSHv2 Server: Diffie-Hellman GEX Reply
SSHv2 Client: New Keys

Alguém pode me explicar cada pacote em detalhes ou sequência de troca de chaves ssh?

    

Answer 1

Antes de mais nada, você deve entender o conceito de uma troca Diffie-Hellman. Ele permite estabelecer um canal entre dois pontos de extremidade com esses recursos:

• Protege contra a escuta. Alguém farejando o canal não pode descriptografá-lo.
• Diffie-Hellman NÃO protege contra ataques man-in-the-middle. Esse tipo de ataque é evitado através da verificação da chave do host. Isso é feito após a troca DH, por isso é criptografado e não pode ser analisado com wireshark neste momento.

• Ele gera um número aleatório que não pode ser determinado por nenhum dos pares sozinho, mas os dois juntos. Este é um conceito interessante para mim.

• No artigo da Wikipédia, aqui está uma estrutura simplificada da troca:

  1. Seja g um número público conhecido de um grupo cíclico finito.
  2. Alice escolhe um número natural aleatório a e envia g ^a para Bob.
  3. Bob escolhe um número natural aleatório b e envia g ^b para Alice.
  4. Alice calcula (g ^b ) ^a = g ^ab
  5. Bob calcula (g ^a ) ^b = g ^ab

Como resultado, eles geraram um segredo aleatório seguro g ^ab .

E AGORA PARA A CAPTURA DO WIRESHARK!

1. SSHv2 Client: Inicio do Exchange de Chaves

   Vários parâmetros de negociação, como compressão e alguns algoritmos de criptografia.

2. Servidor SSHv2: inicialização do Exchange de chaves

   Responder acima

3. Cliente SSHv2: Iniciação do Exchange de Chave Diffie-Hellman

   Negociação dos parâmetros DH sobre o grupo matemático. (Veja RFC4419 seção 3 para mais detalhes).

4. Servidor SSHv2: Resposta de troca de chaves Diffie-Hellman

   Responder acima.

5. Cliente SSHv2: Init Giff Diffie-Hellman

   Primeira troca real de DH. Após a notação do wikipedia, este seria o passo 2 (Alice envia g ^a ).

6. Servidor SSHv2: Diffie-Hellman GEX Reply

   A troca termina (Bob envia g ^b ).

   Depois de receber este pacote, os dois pares conhecem a chave secreta (g ^ab ) e estabelecem um canal pseudo-seguro com ela (seguro contra espionagem casual, mas não contra o interceptor man-in-the-middle). ataques).

7. Cliente SSHv2: novas chaves

   Isso parece uma simples mensagem de confirmação para mim. É pequeno e não contém dados significativos.

   Ok, suponho que há muita coisa acontecendo depois disso (verificação de chave pública do servidor, autenticação do usuário, estabelecimento de canais de dados para shell / sftp / scp / tunnels, etc). Eu não sei os detalhes exatos e (des) felizmente tudo isso é criptografado.

Referências úteis:

1. link
2. link

Answer 2

O cliente e o servidor começam enviando um ao outro as versões de protocolo e software que estão usando.

SSHv2 Client: Key Exchange Init

Aqui, o cliente informa ao servidor os algoritmos que ele suporta para cada função (criptografia, MAC, troca de chaves, autenticação do host, compactação), em ordem de preferência.

SSHv2 Server: Key Exchange Init

O servidor faz o mesmo. Observe que ele pode enviar esta mensagem antes de receber a do cliente.

Nas duas listas de algoritmos, o cliente e o servidor calculam independentemente o mesmo conjunto de criptografia. Por exemplo, eles escolhem o mesmo algoritmo de troca de kex (e ocorre logo depois disso).

SSHv2 Client: Diffie-Hellman Key Exchange Init
SSHv2 Server: Diffie-Hellman Key Exchange Reply
SSHv2 Client: Diffie-Hellman GEX Init
SSHv2 Server: Diffie-Hellman GEX Reply

A troca de chaves Diffie-Hellman permite que o cliente e o servidor acabem com um segredo compartilhado que um observador na rede não pode adivinhar. Por exemplo, eles obterão uma chave para o algoritmo de criptografia desse segredo.

Observe que a resposta do servidor também contém sua chave de host pública (ou certificados). Se for uma chave pública e o cliente nunca a viu, o cliente geralmente pergunta ao usuário se deve confiar nele:

The authenticity of host 'debian.org (130.89.148.14)' can't be established.
ED25519 key fingerprint is SHA256:bNnjFMvzsNhkwzRHwGRbTIUM4XzUjlLrBl/7MzCbndw.

SSHv2 Client: New Keys

Com a mensagem Novas chaves , o cliente significa:

Hey server! All the following messages from me will use the ciphers we just negotiated.

O servidor também deve enviar uma mensagem Novas Chaves para o cliente.

Minha referência principal é o RFC para o protocolo de transporte SSH: link . Essa é a camada mais baixa de SSH, na qual todos os outros serviços SSH (autenticação de usuário, shell, encaminhamento X11, etc) são baseados.