Estou lendo em um livro Linux Admin, de uma editora conhecida:
Quando um cliente inicia o handshake SSH, o servidor solicita a chave pública do cliente e a verifica em relação às chaves públicas permitidas. Se houver uma correspondência, o handshake SSH é bem-sucedido, o servidor compartilha sua chave pública com o cliente e a sessão SSH é estabelecida. Outras comunicações cliente-servidor seguem os fluxos de trabalho padrão de criptografia/descriptografia. O cliente criptografa os dados com sua chave privada, enquanto o servidor descriptografa os dados com a chave pública do cliente. Ao responder ao cliente, o servidor criptografa os dados com sua própria chave privada e o cliente descriptografa os dados com a chave pública do servidor.
Isso está simplesmente errado ou estou perdendo alguma coisa? I afirma que a comunicação da sessão é implementada com criptografia assimétrica, usando dois pares de chaves, um para a direção cliente->servidor e outro para servidor->cliente.
Todas as outras referências da Internet indicam que o servidor e o cliente estabelecem uma chave de sessão simétrica e usam criptografia simétrica durante a sessão...
O livro está errado em praticamente tudo o que foi citado.
(Como o procedimento descrito funcionaria se o cliente usasse autenticação por senha e não tivesse seu próprio par de chaves?)
O livro pode ter sido influenciado pelo (agora completamente obsoleto) protocolo SSHv1, no qual o servidor usava seu par de chaves RSA assimétrico para criptografar/descriptografar algumas coisas (sempre foi RSA em SSHv1), mas mesmo assim era apenas para autenticação e não para criptografia de dados em massa (que ainda usava algoritmos simétricos como 3DES).
Mas isso não é mais feito no SSHv2, que (assim como o TLS) mudou totalmente para codificação baseada em DH e autenticação baseada em assinatura.
Portanto, está atrasado e incompleto. A autenticação do servidor acontece antes da autenticação do cliente, por vários motivos, mas entre eles o fato de que os clientes não necessariamente usam pares de chaves para autenticar – eles podem usar senhas comuns, por exemplo, então você gostaria de autenticar o servidor antes de enviar sua senha .
Além disso, nenhuma dessas chaves é usada para criptografia. Ambas as chaves são usadas apenas para assinar coisas; as chaves de criptografia reais são geradas novas para cada sessão, durante o procedimento de "troca de chaves" que o livro esqueceu de mencionar (geralmente uma forma de DH/ECDH).
A "troca de chaves" do DH é a primeira coisa a acontecer e gera chaves simétricas (o servidor fornece sua chave pública durante esta fase), então a criptografia simétrica é estabelecida e o cliente se autentica no servidor - possivelmente com um par de chaves, mas possivelmente não.
Isto está errado. Embora o SSH use chaves distintas em ambas as direções (cliente-servidor e servidor-cliente), ambos ainda são usados com uma cifra simétrica como AES, portanto não há nenhuma "chave pública" envolvida nisso - o cliente usa a mesma chave simétrica para criptografar dados que o servidor usa para descriptografar.
Praticamente todos os protocolos usam apenas criptografia simétrica para transferência de dados em massa, SSH e TLS funcionam dessa maneira.
Você pode dar uma olhada
ssh -vouplink -v somehostver qual cifra está sendo negociada; ele mostrará o AES ou outra cifra simétrica semelhante em uso em ambas as direções, e essa cifra não possui chaves públicas.