Isso parece simples demais e sinto que perdi algo óbvio, mas o que realmente acontece quando você usa SSH sem gerar um par de chaves?
Uma variante desta pergunta foi feitaaquie assim como a resposta, sempre entendi que sem o par de chaves, o SSH recorre à autenticação por senha.
No entanto, oArtigo da Wikipédiadescreve apenas duas maneiras de usá-lo. Ambos parecem envolver pares de chaves, um gerado manualmente e outro automaticamente.
Existem várias maneiras de usar o SSH; uma delas é usar pares de chaves pública-privada gerados automaticamente para simplesmente criptografar uma conexão de rede e, em seguida, usar a autenticação por senha para fazer logon.
Outra é usar um par de chaves pública-privada gerado manualmente para realizar a autenticação, permitindo que usuários ou programas façam login sem precisar especificar uma senha.
Quando crio uma conexão SSH com um servidor não seguro sem um par de chaves, meu nome de usuário e senha são solicitados e tenho acesso ao shell.
A senha alternativa é um detalhe de implementação e, portanto, não está no wiki? Um par de chaves foi gerado automaticamente, conforme sugerido (em caso afirmativo, como a chave pública chegou ao servidor)? Ou está acontecendo apenas com senha.
Se estiver usando apenas a combinação de senha e nome de usuário, os dados estão sendo criptografados? Se sim, como está sendo criptografado?
Responder1
O artigo da Wikipedia está confundindo diferentes camadas SSHv2. (Poderia ter sidode alguma formacorreto para SSHv1 há uma década, mas é definitivamente simplificado ao nível do absurdo.)
Pares de chaves SSHv2, tanto seus quanto do servidor, são usados paraautenticaçãoapenas, e a configuração da criptografia é sempre feita usando pares de chaves DH gerados temporariamente para cada conexão. Apenas o par de chaves SSH do servidorsinaisdados de configuração de criptografia (para provar a identidade do servidor), enquanto o par de chaves SSH do cliente não é usado para este processo.
No SSHv2, quando você se conecta ao servidor (após ambas as extremidades trocarem listas de algoritmos suportados), a primeira etapa étroca de chaves, que de alguma forma gera uma chave simétrica usada para criptografar toda a conexão. (O servidor também é autenticado como efeito colateral desse processo.)
A maior parte do tempoD–HouECDHserá usado para isso, o que significa:
O cliente gera um par de chaves DH (usado apenas para esta conexão) e envia sua chave pública DH.
O servidor também gera um novo par de chaves DH. Ele também carrega seu par de chaves SSH "host key" do disco.
Então issosinaisa chave pública DH com a chave privada SSH e envia ambas as chaves públicas (bem como a assinatura) ao cliente.
O cliente verifica a assinatura e verifica se a chave pública SSH do servidor está emknown_hosts.
Então ele usa ambosHDchaves (privada do cliente + pública do servidor) para gerar a chave de criptografia compartilhada e descarta seu par de chaves DH.
O servidor também usa ambas as chaves DH (privada do servidor + pública do cliente) para gerar a mesma chave de criptografia compartilhada e também joga fora seu par de chaves DH.
Ambos os lados permitem a criptografia.
(Existem alguns outros métodos de troca de chaves, mas raramente são usados.)
O próximo passo éautenticação de cliente. Observe que neste ponto a conexão já está criptografada, mesmo que a chave SSH do cliente ainda não tenha sido usada!
O cliente envia uma "solicitação de serviço" para autenticação do cliente.
O servidor oferece alguns mecanismos – “senha”, “chave pública”, possivelmente outros.
Se você tiver um par de chaves SSH, o cliente seleciona "chave pública", envia suas chaves públicas SSH e usa sua chave privada SSH para assinar alguns dados aleatórios fornecidos pelo servidor, para provar a propriedade da chave.
Se você não tiver um par de chaves SSH, o cliente seleciona “senha” e envia sua senha diretamente – porém, ainda dentro do túnel criptografado.