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


21

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?



Adicionei algum contexto de segundo plano para 'ssh' na resposta "Sobre arquivos seguros que contêm chaves públicas" na pergunta mencionada por @Gilles: < security.stackexchange.com/questions/20706/… >
IAM_AL_X

Respostas:


33

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.

1
Boa resposta para Gilles, mas minha pergunta é: qualquer servidor pode enviar uma chave pública aleatória e provar que possui a chave pública associada. Como isso prova que o servidor é autêntico?
9786 Alex

@partpartus Eu acho que você quis dizer "e provar que tem a chave privada associada", certo? A idéia é que o cliente envie um valor gerado aleatoriamente (um desafio ) ao servidor, e o servidor faça alguns cálculos com base na chave privada que depende do desafio (para que o servidor não possa fazer o cálculo até receber isso desafio) e isso só pode ser feito com o conhecimento da chave privada.
Gilles 'SO- stop be evil'

Acho que Alex se refere à primeira vez que o cliente se conecta ao servidor. Acho que o cliente confiará no servidor pela primeira vez. Em seguida, o servidor enviará sua chave pública e o cliente poderá autenticar o servidor para as seguintes conexões.
synack 23/06

@ Synack Ah, pela primeira vez? Em vez disso, o cliente pede que o usuário tome a decisão ("Tem certeza de que deseja continuar se conectando (sim / não)?"). O servidor não prova nada nesse momento.
Gilles 'SO- stop be evil'

você está certo, é o usuário que toma a decisão.
synack

2

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.