Há duas coisas importantes acontecendo nas conexões SSH:
Autenticação do servidor & criptografia
O servidor lhe envia sua chave pública e você precisa confiar nela. Você poderia obtê-lo manualmente antes disso e, em um ambiente de segurança ideal, nunca se conectaria a um servidor SSH ANTES de saber que a chave pública dele está correta. Para que servem as CAs, elas assinam uma chave pública de servidores. Na maioria dos ambientes SSH, você apenas aceita o pubkey do servidor como cliente. Esta é a inicial "você quer confiar neste servidor e adicioná-lo à sua lista?" - pergunta. O pubkey do servidor é armazenado em .ssh / known_hosts no cliente em sistemas Linux .
A criptografia real da conexão não é assimétrica. Este é um grande equívoco que muitas pessoas têm sobre criptografia de chave privada / pública. Seria muito lento. O que realmente acontece é que o servidor e o cliente geram um segredo compartilhado (também conhecido como senha longa) que é criptografia simétrica para essa sessão. O cliente e o servidor usam criptografia assimétrica até concordarem com um segredo compartilhado. Depois disso, eles mudam para criptografia simétrica com esse segredo compartilhado como chave.
Esse tipo de criptografia é a mais comum e chamada criptografia híbrida , embora quase todo mundo (erroneamente) a chame de criptografia assimétrica.
Um exemplo de criptografia assimétrica "real" e pura é a criptografia de e-mail com PGP, porque TODAS as mensagens são criptografadas assimetricamente.
Além disso: o segredo compartilhado não é armazenado permanentemente, a cada nova sessão um novo segredo compartilhado é negociado.
Autenticação de cliente
Isso é uma coisa totalmente diferente, é o que pode ser autenticação por senha e / ou chave. A chave pública do cliente (localizada em ~ / .ssh / id_rsa.pub) deve estar presente no arquivo authorized_keys dos servidores (por exemplo, para root: /root/.ssh/authorized_keys). Antes que ssh-copy-id existisse, as pessoas fariam algo como
cat ~/.ssh/id_rsa.pub | ssh root@server "cat >> ~/.ssh/authorized_keys"
para anexar sua chave aos servidores authorized_keys.
O certificado do cliente NÃO é usado para criptografia, apenas para autenticação.
IMPORTANTE Editar: tornou a postagem mais clara em relação a ssh-copy-id para evitar mal-entendidos.
A partir de agora, ssh-copy-id é a melhor maneira prática de adicionar uma chave pública de clientes a um servidor. Acabei de postar o método cat para mostrar quais arquivos são manipulados em ambos os lados para mostrar a conexão entre chaves privadas e públicas e como elas são armazenadas.
Ao usar o gato, há o risco de esquecer um ">" por exemplo, que sobrescreveria o seu arquivo authorized_keys (no Linux "> >" significa anexar, ">" significa sobrescrever). Seja responsável ao manipular arquivos de configuração diretamente. Obrigado @Rallph por apontar isso.