Como remover a verificação estrita de chave RSA no SSH e qual é o problema aqui?


42

Eu tenho um servidor Linux que, sempre que eu conecto, mostra a mensagem que mudou a chave do host SSH:

$ Raiz ssh @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ AVISO: A IDENTIFICAÇÃO DO HOST REMOTA FOI MUDADA! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ É POSSÍVEL QUE ALGUÉM ESTÁ FAZENDO ALGO DESAGRADÁVEL! Alguém pode estar te espionando agora (ataque man-in-the-middle)! Também é possível que a chave do host RSA tenha sido alterada. A impressão digital da chave RSA enviada pelo host remoto é 93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b. Entre em contato com o administrador do sistema. Adicione a chave do host correta em /home/emerson/.ssh/known_hosts para se livrar dessa mensagem. Chave incorreta em /home/emerson/.ssh/known_hosts:377

A chave do host RSA para o host1 foi alterada e você solicitou uma verificação estrita. Falha na verificação da chave do host.

Ele me mantém por alguns segundos conectados e depois fecha a conexão.

host1: ~ / .ssh # Ler do host remoto host1: Redefinição de conexão pelo ponto A conexão com o host1 foi fechada.

Alguém sabe o que está acontecendo e o que eu poderia fazer para resolver esse problema?


1
Isso engana a pergunta anterior: serverfault.com/questions/2988/…
Drew Stephens

Respostas:


68

Por favor, não exclua todo o arquivo known_hosts, conforme recomendado por algumas pessoas, isso anula totalmente o objetivo do aviso. É um recurso de segurança para avisar que um homem no meio do ataque pode ter acontecido.

Sugiro que você identifique por que ele acha que algo mudou, provavelmente uma atualização do SSH alterou as chaves de criptografia devido a uma possível falha de segurança. Você pode remover essa linha específica do seu arquivo known_hosts:

sed -i 377d ~/.ssh/known_hosts

Este d eletes linha 377 como mostrado depois do cólon no aviso:

/home/emerson/.ssh/known_hosts:377

Como alternativa, você pode remover a chave relevante fazendo o seguinte

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

NÃO limpe o arquivo inteiro e verifique se esta é realmente a máquina à qual você deseja se conectar antes de limpar a chave específica.


Não excluiremos mais de 350 servidores devido a uma incompatibilidade de chave. Alguma idéia de por que ele continua fechando a conexão?
Setatakahashi

Ele não é resolvido depois que você remove o registro relevante de known_hosts? Caso contrário, você pode executar o cliente ssh no modo detalhado e colá-lo em algum lugar.
9759 Adam Gibbins

1
Está fechando a máquina porque a chave do host é inválida, como diz. Se você é sério sobre segurança, precisa verificar com o administrador do servidor se a chave do host foi alterada por um motivo legítimo. Nesse caso, você pode substituí-lo, conforme explicado por Adam.
217 Matthew Flaschen

Eu segui sua sugestão, mas $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": caracteres extras no final do comando l, então eu a removi manualmente com vim e funcionou. Thanx!
Luis Ramirez-Monterosa

3
A sintaxe de Adam está quase correta, mas você precisa de um espaço entre o "377" e o "d". Além disso, no OS X, os hosts conhecidos estão localizados em ~ / .ssh / known_hosts; note a falta de um "." no nome do arquivo.
Ktappe 22/10/2015

27

Acho que, embora algumas das respostas aqui abordem o curso de ação recomendado na pergunta do OP, ela não responde totalmente à pergunta.

A pergunta declara "Como remover a verificação estrita de chave RSA no SSH e qual é o problema aqui?"

O problema aqui é, como recomendado por alguns outros, uma alteração no host provavelmente devido à reinstalação do servidor (cenário mais comum). E a solução recomendada é realmente remover a chave incorreta do arquivo .ssh / allowed_keys com um sed embutido.

No entanto, eu não vi nenhuma resposta abordar a parte específica da pergunta " Como remover a verificação estrita de chave RSA no SSH ".

Você pode remover a verificação do StrictHostKey no seu arquivo de configuração ssh, normalmente armazenado em ~/.ssh/config.

Um exemplo de bloco Host é fornecido abaixo:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

A linha especificamente adicionada é a última StrictHostKeyChecking noque faz exatamente isso. Dependendo do seu cenário específico, isso pode ser útil para você, como executar vários contêineres virtualizados em um servidor dedicado, em apenas alguns ips, parar e iniciar outra instância no mesmo ip.


3
+1 Porque esta postagem realmente trata da parte de verificação estrita da mensagem de erro.
Shibumi 24/03

1
+1 de mim também por abordar o conteúdo da pergunta. Dependendo dos fatores, pode haver mais o que fazer. Essa abordagem degrada a verificação do host de "estrito" para "alguns" (minha terminologia). Na minha situação, isso deixou o ssh com permissão para me impedir de entrar, porque a maneira como eu queria entrar era digitar uma senha e isso foi desativado por "algumas" verificações de host. Então você tem que ir em frente e direcionar o ssh para usar / dev / null como o "UserKnownHostsFile". Isso define a verificação de host como "none" em vigor e os DIRE WARNINGS acima se aplicam, portanto, não faça isso globalmente ou permanentemente.
cardiff space man

Esta é realmente uma solução elegante. Obrigado por compartilhar!
LeOn - Han Li

10

Outra maneira de remover StrictHostKeyChecking, quando você só precisa fazer isso para um único servidor:

ssh <server> -o StrictHostKeyChecking=no

Permite fazer login, mas não corrige o problema permanentemente.
Andres Canella

Quando eu faço isso, me dá a chance de adicionar a chave, que então corrige o problema permanentemente
Greg Dougherty

Talvez tenhamos um problema diferente? Estou conectando a um servidor que tinha um IP diferente antes.
Andres Canella

Se você tiver um servidor cujos dados foram alterados, será necessário excluí-lo do arquivo de hosts conhecidos (depois de primeiro estabelecer que a alteração está correta) e adicionar suas novas informações. Se você tiver um novo servidor, -o permitirá que você se conecte ao servidor e adicione suas informações.
Greg Dougherty

Eu acho que é realmente uma boa prática manter o StrictHostKeyChecking definido como YES na sua configuração e usar apenas essa opção quando souber que está se conectando a um novo servidor ou se você alterou as chaves em um servidor antigo.
mohak

5

Primeiro de tudo, esta é a sua máquina? Você mudou conscientemente as chaves do host? Caso contrário, eu ficaria muito preocupado com o fato de algo ter alterado esses dados.

Em segundo lugar, aumente a depuração ssh,

ssh -vvv user@host

e veja o que isso indica, tente também procurar / var / log / secure e / var / log / messages no servidor ao qual você está tentando se conectar para obter pistas, o sshd fornece boas mensagens de erro.

Em terceiro lugar, esta máquina está conectada à Internet? Você realmente deveria permitir logins raiz?


1
+1 para o comentário dos logins root
Fahad Sadah

Tudo o que é necessário para que esse erro ocorra é a máquina de destino que está sendo criada novamente. Se você estiver se conectando a um alvo que está do seu lado de uma DMZ, um ataque do MitM é muito improvável.
Ktappe 22/10/2015

3

Você está recebendo isso porque algo mudou (como nova NIC, novo IP, alteração no software do servidor etc.). O foco de segurança tem um bom artigo sobre proteção de chave de host SSH .

Apenas remova a chave (usando SFTP ou similar) do servidor, editando o $HOME/.ssh/known_hostsarquivo e aceite a nova na próxima conexão.

Sua conexão pode estar caindo devido à configuração StrictHostKeyChecking. Veja este tópico para um problema semelhante.


2
Nããão, por favor, não faça isso. Isso anula totalmente toda a segurança que esse recurso fornece. Por favor, remova apenas a chave específica que mudou, nem todas as opções conhecidas.
447 Adam Gibbins

5
Não recomendei remover o arquivo known_hosts, recomendamos editá-lo e remover a chave dele.

Opa, desculpe, mal interpretado.
447 Adam Gibbins

2
Essa mensagem certamente não pode ser acionada por um novo endereço IP, muito menos por uma nova NIC. Veja a resposta correta de Adam Gibbins.
Bortzmeyer 8/09

1
Antes de votar (estou achando as pessoas muito felizes com isso), faça sua pesquisa. Leia este artigo do Security Focus, securityfocus.com/infocus/1806 . Cito um pouco: "Por que uma chave de host pode mudar? A máquina à qual você deseja se conectar foi movida para um nome DNS ou endereço IP diferente ou foi substituída por uma nova totalmente". Se uma resposta estiver terrivelmente incorreta, permita a chance de uma correção. Afinal, este é um wiki.

3

Como o 'host' [definido em termos gerais, pode ser tudo, de uma reinstalação / inicialização múltipla a um computador totalmente diferente com um endereço IP ao qual você se conectou antes, por exemplo] parece que o cliente ssh mudou, está fornecendo a você erro.

Não é necessário desativar a verificação rigorosa, nem é sensível a exclusão por atacado de chaves salvas.

É bem possível ter duas chaves diferentes listadas em known_hosts para um nome de host ou endereço IP específico; fornecendo a você duas alternativas, conforme você acha que pode precisar da chave 'antiga' que está atualmente armazenada em

Exclua a chave específica à qual está se referindo, em l377 de known_hosts para o OP, ou mantenha ambos

A maneira mais simples de manter os dois, evitando a exclusão de chaves em known_hosts, é

  1. Edite known_hosts para adicionar # no início da entrada 'antiga' referenciada em known_hosts [@ l377] temporariamente
  2. Conecte [ssh ao host], aceite a solicitação para adicionar a nova chave 'automaticamente'
  3. Em seguida, edite o unknown_hosts para remover o #

mais respostas em "Adicionar chave de host correta emhos_conhecidos" / várias chaves de host ssh por nome de host?


Eu não sabia sobre o truque das duas chaves. Este não é um comportamento documentado, é?
hackerb9 29/01
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.