Quais são as etapas que ocorrem durante o estabelecimento de uma conexão ssh em uma máquina que usa autenticação baseada em senha?

Question

Eu quero saber o que acontece nos bastidores ao estabelecer uma conexão ssh, quero dizer, até chegarmos ao shell em um Linux de uma máquina Linux. Eu sei que a senha não é enviada em texto simples em uma conexão ssh. Então, o que eles fazem para criptografar a conexão. Aqui estou assumindo que não gerou minhas chaves públicas / privadas. Eu uso senha para autenticação. Então eu acho que não pode haver uma troca de chaves antes de garantir a conexão. Eu procurei no google e no serverfault mas sem hits. O mais perto que cheguei no serverfault foi este post O que exatamente o ssh envia ao realizar negociações importantes? .
O post acima assume que o usuário está se conectando via troca de chave pública. Mas eu estou procurando um caso de garantir a conexão sem as chaves públicas / privadas. Como ele criptografa a conexão antes mesmo de eu digitar a senha. O que é usado para proteger a conexão para que a senha não envie texto simples?

    

Answer 1

Quando você instala o SSH e o inicia pela primeira vez, ele gera chaves públicas e privadas para a máquina , que são as mesmas para todos os usuários. Na conexão, ambas as máquinas trocarão suas partes de chave pública (em texto simples) e as usarão para criptografar a comunicação entre os hosts. Após a troca de chaves, a comunicação passará para o modo criptografado.

Em todos os usuários ~/.ssh/known_hosts , as chaves serão armazenadas e comparadas com as enviadas na próxima conexão. Esse é o motivo pelo qual você obterá um erro se tentar conectar-se a uma máquina que você reinstalou recentemente: ao fazer isso, você gerou um novo par de chaves de máquina e isso não corresponde à versão em cache, o que também pode significar uma tentativa ataque.

    

Answer 2

A RFC 4252 explica como a autenticação usando o SSH funciona e quais etapas estão envolvidas. É claro que a especificação é complicada de ler, portanto a maneira mais fácil pode estar executando ssh com um ou mais sinalizadores verbosos ( -v ), já que eles imprimem todo o resultado de depuração explicando o que está fazendo.

Isto é o que parece para um caso de amostra (eu mudei nomes de usuário e host). Usar ssh -vv em vez de ssh -v fornecerá ainda mais detalhes:

[user@gromp ~]$ ssh -v [email protected] 
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.org [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'example.org' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive,hostbased
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
[[email protected]~]$