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

Question

Eu li sobre a configuração de chaves ssh no Linux e tenho algumas perguntas. Me corrija se eu estiver errado ...

Digamos que o host tr-lgto deseje 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 a known_hosts no tr-lgto. Se o tr-mdm quiser verificar se é o verdadeiro tr-lgto, então tr-lgto tem que gerar um par de chaves e adicionar a chave pública a authorized_keys no tr-mdm.

Pergunta 1 : Não há campo 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 pasta .ssh . Devemos adicionar a chave pública a cada um dos arquivos known_hosts ?

Pergunta 2 : Descobri que ssh-keyscan -t rsa tr-mdm retornará a chave pública do tr-mdm. Como eu sei a qual usuário esta chave pertence? Além disso, a chave pública em /root/.ssh/ é diferente do que esse comando retorna. Como isso pode ser?

    

Answer 1

Você está misturando a autenticação da máquina do servidor com a máquina cliente e a autenticação do usuário na máquina do 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 para o cliente e prova (graças a criptografia de chave pública ) para o cliente que conhece a chave privada associada. Isto autentica o servidor: se esta parte do protocolo for bem sucedida, o cliente sabe que o servidor é quem finge que é.

O cliente pode verificar se o servidor é conhecido, e não algum servidor desonesto tentando passar como o caminho certo. O SSH fornece apenas um mecanismo simples para verificar a legitimidade do servidor: ele lembra os servidores aos quais você já se conectou, no arquivo ~/.ssh/known_hosts da máquina cliente (há também um arquivo de todo o sistema /etc/ssh/known_hosts ). A primeira vez que você se conecta a um servidor, você precisa verificar, por algum outro meio, se 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 que está prestes a se conectar, poderá adicioná-la ao ~/.ssh/known_hosts no cliente manualmente.

Autenticar o servidor tem que ser feito antes de você enviar qualquer dado confidencial para ele. Em particular, se a autenticação do usuário envolve uma senha, a senha não deve ser enviada para um servidor não autenticado.

Autenticação do usuário

O servidor só 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 efetuar login; o servidor então 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-as. A tentativa de login é aceita se o usuário provar que sabe que a chave privada e a chave pública estão na lista de autorizações da conta ( ~/.ssh/authorized_keys no servidor).
• Outro tipo de método envolve a delegação de parte do trabalho de autenticação do usuário para a 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 que é usado ao contrário e, em seguida, confia no cliente para autenticar o usuário.

Answer 2

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