Algoritmo de estabelecimento de conexão SSH

(O título inicial do artigo “Algoritmo de operação do protocolo SSH” foi alterado de acordo com as recomendações de Vindicar , Karroplan e outros membros da comunidade local)

Ao ler periodicamente artigos sobre SSH, notei que seus autores às vezes não têm idéia de como esse protocolo funciona. Na maioria dos casos, eles estão limitados a considerar o tópico de geração de chaves e descrever as opções dos comandos principais. Mesmo os administradores de sistema experientes costumam ter total bobagem ao discutir questões de SSH, emitindo opus com estilo: os dados transmitidos são criptografados com a chave pública SSH do cliente e descriptografados com a chave privada, ou: o algoritmo RSA é usado para criptografar dados durante a transmissão.

Vou tentar esclarecer a operação do protocolo SSH e, ao mesmo tempo, considerar o papel do algoritmo RSA e das chaves de autorização do usuário ...

imagem

O algoritmo do protocolo SSH pode ser dividido em três níveis, cada um dos quais localizado acima do anterior: transporte (abertura de um canal seguro), autenticação, conexão. Por uma questão de integridade da imagem, também adicionarei um nível de configuração de conexão de rede, embora oficialmente esse nível esteja abaixo do SSH.

1. Estabeleça uma conexão TCP


Não vou me debruçar sobre o princípio da pilha TCP / IP, pois esse tópico está bem documentado no Runet. Se necessário, você pode encontrar informações com facilidade.

Nesse ponto, o cliente se conecta ao servidor na porta TCP especificada na opção Porta (padrão: 22) no arquivo de configuração do servidor / etc / ssh / sshd_config.

2. Abrindo um canal seguro


2.1 Troca de identidade

Depois que a conexão TCP é estabelecida, o cliente e o servidor (doravante referidos como as partes) trocam versões do protocolo SSH e outros dados de suporte necessários para determinar a compatibilidade do protocolo e selecionar algoritmos de operação.

2.2 Escolha de algoritmos: troca de chaves, criptografia, compactação, etc.

Ao trabalhar com SSH, alguns algoritmos são usados, alguns deles para criptografia, o segundo para troca de chaves, o terceiro para compactação dos dados transmitidos etc. Nesta etapa, as partes enviam listas de algoritmos suportados, os algoritmos no topo de cada lista têm a prioridade mais alta. Em seguida, os algoritmos nas listas obtidas são comparados com os algoritmos disponíveis no sistema e o primeiro correspondente a cada lista é selecionado.

Uma lista dos algoritmos de troca de chaves disponíveis no lado do cliente (usados ​​para obter uma chave de sessão) pode ser visualizada com o comando:

ssh -Q kex 

Lista de algoritmos simétricos disponíveis no sistema (usado para criptografia de canal):

 ssh -Q cipher 

A lista de tipos de chave para autorização no cliente:

 ssh -Q key-cert 

Atualizado por observação onix74 :
Todos os comandos usados ​​na publicação são relevantes para o OpenSSH versão 7.6 do Ubuntu 18.04 LTS.

2.3 Obtendo uma chave de criptografia de sessão

O processo de obtenção de uma chave de sessão pode diferir dependendo da versão do algoritmo, mas em termos gerais ele se resume ao seguinte:

  • O servidor envia sua chave ao cliente (DSA, RSA, etc., de acordo com o contrato entre as partes produzido na cláusula 2.2).
  • Se o cliente se conectar a este servidor pela primeira vez (conforme indicado pela falta de uma entrada no arquivo /home/username/.ssh/known_hosts no cliente), o usuário será solicitado a confiar na chave do servidor. Se a conexão com este servidor já foi estabelecida anteriormente, o cliente compara a chave enviada com a chave registrada em /home/username/.ssh/known_hosts. Se as chaves não coincidirem, o usuário receberá um aviso sobre uma possível tentativa de invasão. No entanto, você pode pular esta verificação se chamar ssh com a opção StrictHostKeyChecking:
     ssh -o StrictHostKeyChecking=no username@servername 
    Além disso, se o usuário precisar excluir a chave antiga do servidor (por exemplo, quando houver uma certeza exata de que a chave foi alterada no servidor), o comando será usado:
     ssh-keygen -R servername 

  • Depois que o cliente determina a confiança na chave do servidor, usando uma das implementações (a versão é definida na Seção 2.2) do algoritmo Diffie-Hellman, o cliente e o servidor geram uma chave de sessão que será usada para criptografia de canal simétrica.

Uma chave de sessão é criada exclusivamente para a vida útil do canal e é destruída quando a conexão é fechada.

3. Autenticação de cliente


E somente agora, quando o cliente e o servidor estabelecem um canal para transmissão de dados criptografados, eles podem se autenticar com uma senha ou chaves.

Em termos gerais, a autenticação de chave ocorre da seguinte maneira:

  • O cliente envia ao servidor um nome de usuário (nome de usuário) e sua chave pública.
  • O servidor verifica o arquivo /home/username/.ssh/authorized_keys quanto à chave pública enviada pelo cliente. Se a chave pública for encontrada, o servidor gera um número aleatório e o criptografa com a chave pública do cliente, após o qual o resultado é enviado ao cliente.
  • O cliente descriptografa a mensagem com sua chave privada e envia o resultado ao servidor.
  • O servidor verifica o resultado para uma correspondência com o número que ele originalmente criptografou com a chave pública do cliente e, se corresponder, considera a autenticação bem-sucedida.

4. Nível de Conexão


Após executar todos os procedimentos acima, o usuário tem a oportunidade de enviar comandos para o servidor ou copiar arquivos.

Nesse nível, é fornecido: multiplicação de canais (a capacidade de operar vários canais em um servidor, combinando-os em um canal), tunelamento, etc.

Da teoria à prática


Bem, agora, eu acho, os leitores têm uma pergunta completamente lógica: por que você precisa conhecer todos esses detalhes do protocolo SSH, se, para o trabalho diário, existe conhecimento suficiente dos comandos de criação de chaves (ssh-keygen), abrindo uma sessão de terminal (ssh), transferência de arquivos ( scp)?

Como resposta, podemos lembrar o tópico de alterar a porta SSH padrão para outra, que constantemente se torna a causa do holivar em Habr ...

Na minha própria prática, não recordo um único servidor olhando para a rede externa que não seria batida diariamente na porta 22. Em uma situação em que o SSH trabalha para você em uma porta padrão (e não é protegida por nada), mesmo que a autenticação por chaves e sem suposições de senha sejam assustadoras, devido a solicitações constantes de clientes desonestos, o servidor ainda é forçado a fazer muito trabalho inútil: estabeleça uma conexão TCP, selecione algoritmos, gere uma chave de sessão, envie solicitações de autenticação, escreva um arquivo de log.

Em uma situação em que não há nada na 22ª porta, ou a porta está protegida usando iptables (ou complementos como fail2ban), o invasor cai no estágio de estabelecer uma conexão TCP.

O mais interessante descrito parece uma tabela *
ConfiguraçãoChance de hackersPerdas de inundação **
22 porto
autorização de senha,
sem proteção
altoalto
22 porto
autorização chave
sem proteção
média ***alto
22 porto
autorização chave
proteção baseada na restrição de tentativas de autorização com falha
baixomédio ****
Porta não padrão,
autorização de senha,
sem proteção
altobaixo
Porta não padrão,
autorização chave
sem proteção
média ***baixo
Porta não padrão,
autorização chave
proteção baseada na restrição de tentativas de autorização com falha
baixobaixo

* - os valores dos parâmetros (alto, médio, baixo) são de natureza relativa e servem apenas para comparar indicadores.
** - significa o consumo de recursos do servidor (processador, disco, canal de rede etc.) para processar uma avalanche de solicitações que geralmente vão para a porta 22.
*** - hackear se as chaves RSA forem usadas para autorização é muito difícil, mas um número ilimitado de tentativas de autorização torna isso possível.
**** - o número de tentativas de autorização é limitado, mas o servidor ainda precisa processá-las a partir de um grande número de intrusos.

Materiais adicionais


Source: https://habr.com/ru/post/pt425637/


All Articles