Autenticação baseada em chave SSH: known_hosts vs allowed_keys

Eu li sobre a configuração de chaves ssh no Linux e tenho algumas perguntas. Corrija-me se eu estiver errado…

Digamos que o host tr-lgto queira se conectar ao host tr-mdm usando ssh. Se queremos ter certeza de que é o verdadeiro tr-mdm, geramos um par de chaves no tr-mdm e adicionamos a chave pública known_hostsno tr-lgto. Se o tr-mdm quiser verificar se é o verdadeiro tr-lgto, o tr-lgto precisará gerar um par de chaves e adicionar a chave pública authorized_keysno tr-mdm.

Pergunta 1 : Não há campo de usuário no arquivo known_hosts, apenas endereços IP e nomes de host. O tr-mdm pode ter muitos usuários, cada um com sua própria .sshpasta. Devemos adicionar a chave pública a cada um dos known_hostsarquivos?

Questão 2 : Descobri que ssh-keyscan -t rsa tr-mdmretornará a chave pública do tr-mdm. Como sei a que usuário essa chave pertence? Além disso, a chave pública /root/.ssh/é diferente do que esse comando retorna. Como isso pode ser?

Você está misturando a autenticação da máquina servidor à máquina cliente e a autenticação do usuário na máquina servidor.

Autenticação do servidor

Uma das primeiras coisas que acontecem quando a conexão SSH está sendo estabelecida é que o servidor envia sua chave pública ao cliente e comprova (graças à criptografia de chave pública ) ao cliente que conhece a chave privada associada. Isso autentica o servidor: se essa parte do protocolo for bem-sucedida, o cliente saberá que o servidor é quem ele finge ser.

O cliente pode verificar se o servidor é conhecido e não um servidor não autorizado que está tentando passar como o correto. O SSH fornece apenas um mecanismo simples para verificar a legitimidade do servidor: ele lembra dos servidores aos quais você já se conectou, no ~/.ssh/known_hostsarquivo na máquina cliente (também há um arquivo em todo o sistema /etc/ssh/known_hosts). Na primeira vez em que você se conecta a um servidor, é necessário verificar por outros meios que a chave pública apresentada pelo servidor é realmente a chave pública do servidor ao qual você deseja se conectar. Se você tiver a chave pública do servidor ao qual está prestes a se conectar, poderá adicioná-la a~/.ssh/known_hosts manualmente no cliente.

A autenticação do servidor deve ser feita antes de você enviar dados confidenciais. Em particular, se a autenticação do usuário envolver uma senha, a senha não deverá ser enviada para um servidor não autenticado.

Autenticação de usuário

O servidor permite que um usuário remoto efetue login se esse usuário puder provar que tem o direito de acessar essa conta. Dependendo da configuração do servidor e da escolha do usuário, o usuário pode apresentar uma das várias formas de credenciais (a lista abaixo não é completa).

• O usuário pode apresentar a senha da conta na qual ele está tentando fazer login; o servidor verifica se a senha está correta.
• O usuário pode apresentar uma chave pública e provar que possui a chave privada associada a essa chave pública. Esse é exatamente o mesmo método usado para autenticar o servidor, mas agora o usuário está tentando provar sua identidade e o servidor está verificando-os. A tentativa de login será aceita se o usuário provar que conhece a chave privada e a chave pública está na lista de autorizações da conta (~/.ssh/authorized_keys no servidor).
• Outro tipo de método envolve delegar parte do trabalho de autenticação do usuário na máquina cliente. Isso acontece em ambientes controlados, como empresas, quando muitas máquinas compartilham as mesmas contas. O servidor autentica a máquina cliente pelo mesmo mecanismo usado de maneira inversa e depois conta com o cliente para autenticar o usuário.

Meus amigos me deram a resposta. Por padrão, key identifica uma máquina e não um usuário. Portanto, as chaves são armazenadas em / etc / ssh /. É por isso que obtive uma chave diferente daquela armazenada em /root/.ssh