O arquivo known_hosts permite que o cliente autentique o servidor, para verificar se ele não está se conectando a um personificador. O arquivo authorized_keys permite o servidor autentica o usuário.

Autenticação do servidor

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

O cliente pode verificar se o servidor é conhecido, e não algum servidor invasor tentando passar como o certo. 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 na máquina cliente (também há um sistema em todo o arquivo /etc/ssh/known_hosts). A primeira vez que você se conectar a um servidor, será necessário verificar por algum outro meio se a chave pública apresentada pelo servidor é realmente a chave pública do servidor ao qual deseja se conectar. Se você tiver a chave pública do servidor ao qual está prestes a se conectar, pode adicioná-la a ~/.ssh/known_hosts no cliente manualmente.

A propósito, known_hosts pode conter qualquer tipo de chave pública suportada pela implementação SSH, não apenas DSA (também RSA e ECDSA).

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

Autenticação do usuário

O servidor só permite que um usuário remoto faça login se esse usuário podem provar que têm 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 é exaustiva).

• O usuário pode apresentar a senha para a conta na qual ele está tentando entrar; 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. Este é 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. A tentativa de login é aceita se o usuário provar que conhece a chave privada e a chave pública está na lista de autorização da conta (~/.ssh/authorized_keys no servidor).
• Outro tipo de método consiste em delegar parte do trabalho de autenticação do usuário à 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, então confia no cliente para autenticar o usuário.

Comentários

• obrigado, isso é muito útil. é correto dizer que o arquivo known_hosts é mantido no cliente enquanto o arquivo authorized_key é mantido no servidor
• @Ankit Sim, esse é o caso.
• Eu tenho os dois arquivos no servidor e ssh para testá-lo. Mas os 2 arquivos têm conteúdos diferentes. Então as chaves são diferentes nesses arquivos?
• @Timo As chaves são completamente unr exaltado. Uma é a chave de uma máquina, a outra é a chave de um usuário.
• @Gilles Então, uma vez que a entrada para uma chave pública ‘ do servidor é adicionada para o arquivo known_hosts na máquina ‘ do cliente, qualquer sessão SSH subsequente entre os dois não ‘ t exige que o servidor prove que possui a chave privada correta?

Esses dois arquivos são usados por SSH , mas para finalidades completamente diferentes, o que poderia facilmente explicar sua confusão.

Chaves autorizadas

Por padrão, o SSH usa contas de usuário e senhas que são gerenciadas pelo sistema operacional host. (Bem, na verdade gerenciado por PAM , mas essa distinção provavelmente não é muito útil aqui.) O que isso significa é que quando você tenta se conectar ao SSH com o nome de usuário “bob” e alguma senha que o programa do servidor SSH pedirá ao SO ” Eu tenho um cara chamado “bob” que está me dizendo que sua senha é “wonka”. Posso deixá-lo entrar? ” Se a resposta for sim, o SSH permite que você se autentique e siga em frente.

Além das senhas SSH também permitirá que você use o que “é chamado de criptografia de chave pública para identificá-lo. O algoritmo de criptografia específico pode variar, mas geralmente é RSA ou DSA , ou mais recentemente ECDSA . Em qualquer caso, quando você configurar suas chaves, usando o ssh-keygen programa, você cria dois arquivos. Um que é sua chave privada e outro que é sua chave pública. Os nomes são bastante próprios -explanatório. Por definição, a chave pública pode ser espalhada como sementes de dente de leão ao vento, sem comprometê-lo. A chave privada deve ser sempre mantida no mais estrito sigilo.

Então, o que você faz é colocar sua chave pública digite no arquivo authorized_keys. Então, quando você tentar se conectar ao SSH com o nome de usuário “bob” e sua chave privada irá perguntar ao SO ” Eu tenho esse cara chamado “bob”, pode estar aqui? ” Se a resposta é sim, então o SSH inspecionará sua chave privada e verificará se a chave pública no arquivo authorized_keys é seu par. Se ambas as respostas forem sim, então você tem permissão para entrar.

Hosts conhecidos

Muito parecido com como o arquivo authorized_keys é usado para autenticar usuários o arquivo known_hosts é usado para autenticar servidores. Sempre que o SSH é configurado em um novo servidor, ele sempre gera uma chave pública e privada para o servidor, assim como você fez para o seu usuário. Cada vez que você se conecta a um servidor SSH, ele mostra sua chave pública, junto com uma prova de que possui a chave privada correspondente. Se você não tiver sua chave pública, seu computador irá solicitá-la e adicioná-la ao arquivo known_hosts. Se você tiver a chave e ela corresponder, conecte-se imediatamente. Se as chaves não corresponderem, você receberá um grande aviso desagradável. É onde as coisas começam a ficar interessantes. As 3 situações em que normalmente ocorre uma incompatibilidade de chave são:

1. A chave mudou no servidor. Isso pode ocorrer durante a reinstalação do SO ou em alguns sistemas operacionais a chave é recriada ao atualizar o SSH.
2. O nome do host ou endereço IP que você está conectando costumava pertencer a um servidor diferente. Pode ser uma reatribuição de endereço, DHCP ou algo semelhante.
3. Malicioso man- um ataque intermediário está acontecendo. Esta é a principal coisa contra a qual a verificação de chave está tentando protegê-lo.

Em ambos os casos, known_hosts e authorized_keys, o programa SSH está usando criptografia de chave pública para identificar o cliente ou o servidor.

Comentários

• ” Cada vez que você se conecta a um servidor SSH, ele apresenta sua chave privada para provar sua identidade. ” Espero que não! Presumo que você quis dizer sua chave pública . Se um servidor me apresentasse, o cliente, com sua chave privada – ele (A) não ‘ funcionaria para eu autenticá-lo e (B) é uma indicação de que o servidor é assim mal configurado para que eu pare de fazer negócios com ele imediatamente. As chaves privadas só devem estar acessíveis na máquina de origem por usuários designados. Esse ‘ é meio que o ponto. 😉
• Esta resposta me ajudou mais do que a aceita (:
• Se eu ssh para um servidor local (IP local), e depois do mesmo computador, mas agora remotamente conectar-se ao mesmo servidor (IP público) irá acionar chaves incompatíveis? Como você pode mitigar isso?

Sobre arquivos seguros que contêm chaves públicas

Para ajudá-lo a entender como “known_hosts” e “authorized_keys” são diferentes, aqui está um contexto que explica como esses arquivos se encaixam em “ssh”. Esta é uma simplificação excessiva ; há muito mais recursos e complicações no “ssh” do que os mencionados aqui.

Associações são fontes confiáveis

Embora tenha sido dito que os valores de chave pública “podem ser espalhados com segurança como sementes ao vento”, tenha em mente que é o O jardineiro, não a vagem, é quem decide quais sementes se estabelecem no jardim. Embora uma chave pública não seja secreta, é necessária uma proteção forte para preservar a associação confiável da chave com o que a chave está autenticando. Os lugares encarregado de fazer esta associação incluir “known_hosts”, “authorized_keys” e “Autoridade de certificação” listagens.

As fontes confiáveis usadas por “ssh”

Para uma chave pública ser relevante para “ssh,” a chave deve ser registrada com antecedência e armazenada no arquivo seguro apropriado. (Esta verdade geral tem uma exceção importante, que será discutida mais tarde.) O servidor e o cliente têm cada um seu próprio, armazenado com segurança lista de chaves públicas; um login terá sucesso apenas se cada lado estiver registrado com o outro.

• “known_hosts” reside no clie nt
• “authorized_keys” reside no servidor

O arquivo seguro do cliente é chamado de “known_hosts”, e o arquivo seguro do servidor é chamado “authorized_keys” . Esses arquivos são semelhantes em que cada um tem texto com uma chave pública por linha, mas eles têm diferenças sutis no formato e uso.

Os pares de chaves são usados para autenticação

Um público -par de chaves privadas são usados para realizar “criptografia assimétrica.” O programa “ssh” pode usar criptografia assimétrica para autenticação, onde uma entidade tem que responder a um desafio para provar sua identidade. O desafio é criado pela codificação com uma chave e respondido pela decodificação com a outra chave. (Observe que a criptografia assimétrica é usada apenas durante a fase de login; então, “ssh” (TSL / SSL) muda para outra forma de criptografia para lidar com o fluxo de dados.)

Um par de chaves para servidor, outro para cliente

Em “ssh”, ambos os lados (cliente e servidor) suspeitam um do outro; este é um aprimoramento em relação ao antecessor de “ssh”, que era “telnet”. Com o “telnet”, o cliente foi solicitado a fornecer uma senha, mas o servidor não foi verificado. A falta de verificação permitiu a ocorrência de ataques “man-in-the-middle”, com consequências catastróficas para a segurança. Em contraste, no processo “ssh”, o cliente não entrega nenhuma informação até que o servidor primeiro responda a um desafio.

As etapas da autenticação “ssh”

Antes de compartilhar qualquer informação de login, o cliente “ssh” primeiro elimina a oportunidade de um ataque man-in-the-middle desafiando o servidor a provar “Você é realmente quem penso que é?” Para fazer esse desafio, o cliente precisa saber a chave pública que está associada ao servidor de destino. O cliente deve encontrar o nome do servidor no arquivo “host_conhecidos”; a chave pública associada está na mesma linha, após o nome do servidor. A associação entre o nome do servidor e a chave pública deve ser mantida inviolável; portanto, as permissões em o arquivo “known_hosts” deve ser 600 – ninguém mais pode escrever (nem ler).

Assim que o servidor for autenticado, ele terá a chance de desafiar o cliente. A autenticação envolverá um dos usuários chaves encontradas em “authorized_keys”. (Quando nenhuma dessas chaves funciona, o processo “sshd” recorre à autenticação de estilo de senha.)

Os formatos de arquivo

Então, para ” ssh “, como em qualquer processo de login, existem listas de” amigos “, e apenas aqueles na lista podem tentar passar um desafio. Para o cliente, o arquivo” known_hosts “é uma lista de amigos que podem agir como servidores (hosts); eles são listados por nome. Para o servidor, a lista de amigos equivalente é o arquivo “authorized_keys”; mas não há nomes nesse arquivo, já que o public As próprias chaves c agem como identificadores. (O servidor não se importa de onde vem o login, mas apenas para onde ele está indo. O cliente está tentando acessar uma conta específica, o nome da conta foi especificado como um parâmetro quando “ssh” foi invocado. Lembre-se de que o O arquivo “authorized_keys” é específico para essa conta, já que o arquivo está no diretório inicial dessa conta.)

Embora haja muitos recursos que podem ser expressos em uma entrada de configuração, o uso básico e mais comum tem os seguintes parâmetros. Observe que os parâmetros são separados por caracteres de espaço.

Para “known_hosts”:

{server-id} ssh-rsa {public-key-string} {comment} 

Para “authorized_keys”:

ssh-rsa {public-key-string} {comment} 

Observe que o token ssh-rsa indica que o algoritmo usado para codificação é “rsa”. Outros algoritmos válidos incluem “dsa” e “ecdsa”. Portanto, um token diferente pode tomar o lugar do ssh-rsa mostrado aqui.

Deixe “ssh” configurar automaticamente o Entrada “known_hosts”

Em ambos os casos, se th A chave pública não é encontrada em um arquivo seguro, então a criptografia assimétrica não acontece. Conforme mencionado anteriormente, há uma exceção a essa regra.Um usuário pode escolher conscientemente o risco de um ataque man-in-the-middle ao fazer login em um servidor que não está listado no arquivo “s” known_hosts “do usuário. O programa” ssh “avisa o usuário, mas se o usuário optar por seguir em frente, o cliente “ssh” permite “apenas desta vez”. Para garantir que aconteça apenas uma vez, o processo “ssh” configura automaticamente o arquivo “known_hosts” com as informações necessárias, solicitando ao servidor o public-key e, em seguida, gravá-la no arquivo “known_hosts”. Essa exceção subverte totalmente a segurança, permitindo que o adversário forneça a associação de um nome de servidor com uma chave pública. Esse risco de segurança é permitido porque torna as coisas muito mais fácil para tantas pessoas. Claro, o método correto e seguro teria sido o usuário inserir manualmente uma linha com o nome do servidor e a chave pública no arquivo “known_hosts” antes de tentar fazer o login no servidor. (Mas para situações de baixo risco, o trabalho extra pode ser inútil.)

Os relacionamentos um-para-muitos

Uma entrada no arquivo “s” known_hosts “do cliente tem o nome de um servidor e uma chave pública que é aplicável à máquina servidor. O servidor tem uma única chave privada que é usada para responder a todos os desafios, e a entrada “s” known_hosts “do cliente deve ter a chave pública correspondente. Portanto, todos os clientes que acessam um determinado servidor terão a mesma chave pública em seu arquivo “host_conhecidos”. A relação 1: N é que a chave pública de um servidor pode aparecer em muitos arquivos “hospedeiros_conhecidos” do cliente.

Uma entrada no arquivo “chaves_ autorizadas” identifica que um cliente amigável tem permissão para acessar a conta. O amigo pode usar o mesmo par de chaves pública-privada para acessar vários servidores diferentes. Isso permite que um único par de chaves seja autenticado em todos os servidores já contatados. Cada uma das contas de servidor alvo teria a entrada de chave pública idêntica em seus arquivos “authorized_keys”. A relação 1: N é que a chave pública de um cliente pode aparecer nos arquivos “authorized_keys” para várias contas em vários servidores.

Às vezes, os usuários que trabalham em várias máquinas clientes replicarão o mesmo par de chaves; normalmente isso é feito quando um usuário trabalha em uma mesa e um laptop. Como as máquinas do cliente são autenticadas com chaves idênticas, elas corresponderão à mesma entrada nas “chaves” autorizadas “do servidor.

Localização das chaves privadas

Para o lado do servidor, um processo do sistema , ou daemon, trata de todas as solicitações de login “ssh” recebidas. O daemon é denominado “sshd”. A localização da chave privada depende da instalação SSL, por exemplo, a Apple a coloca em /System/Library/OpenSSL, mas depois de instalar sua própria versão do OpenSSL, o local será /opt/local/etc/openssl.

Para o lado do cliente, você invoca “ssh” (ou “scp” ) quando você precisar. Sua linha de comando incluirá vários parâmetros, um dos quais pode especificar opcionalmente qual chave privada usar. Por padrão, o par de chaves do lado do cliente costuma ser chamado de $HOME/.ssh/id_rsa e $HOME/.ssh/id_rsa.pub.

Resumo

A conclusão é que tanto “known_hosts” quanto “authorized_keys” contêm chaves públicas, mas …

• host_conhecidos – o cliente verifica se o host é genuíno
• authorized_keys – o host verifica se o login do cliente é permitido

Comentários

• clientes SSH geralmente don ‘ t temos chaves. As chaves públicas listadas em authorized_keys identificam usuários, não máquinas.
• Obrigado. Esta é uma explicação muito clara e facilmente compreensível das relações entre os arquivos e as chaves.

Não é verdade.

O arquivo known_hosts contém a impressão digital do host. Não é a chave pública ou privada do host remoto.

Ela é gerada a partir da chave – mas enfaticamente NÃO é a chave em si.

Se você enviar um SFTP para um endereço que pode resolver para vários hosts (variados) (com carga balanceada etc.), você deve adicionar as impressões digitais de todos os pontos de extremidade possíveis, ou funcionará inicialmente e falhará quando for roteado para o segundo (ou subsequente) host.

Comentários

• erm olhe seu arquivo known_hosts e compare-o com uma impressão digital do host quando você se conectar … Isso deve esclarecer um pouco. Além disso, seu exemplo seria exatamente o mesmo, independentemente se fossem impressões digitais ou chaves públicas no arquivo known_hosts.