Questão Como corrigir o aviso sobre a chave do host ECDSA


Estou tentando configurar o SSH sem senha em um servidor Ubuntu com ssh-copy-id myuser@myserver, mas estou recebendo o erro:

Aviso: a chave do host ECDSA para 'myserver' difere da chave do endereço IP '192.168.1.123'

O que está causando isso e como faço para corrigir isso? Eu tentei apagar o .ssh diretório na máquina remota e executando ssh-keygen -R "myserver" localmente, mas isso não resolve o erro.


210


origem


no meu caso, eu mudo o servidor (ip) bind com o domínio, então o The ECDSA host key for server has changed. Meu caminho é remover a cadeia de cache relacionada sobre o domínio em ~/.ssh/known_hosts. Então o ssh funciona. - Ninja


Respostas:


Remova a chave em cache para 192.168.1.123 na máquina local:

ssh-keygen -R 192.168.1.123

300



Não funcionou para mim no servidor Debian recém-instalado no trabalho quando SSHing de casa. Além disso, a resposta é bastante concisa. - Chris K
/home/wf/.ssh/known_hosts atualizado. Conteúdo original retido como /home/wf/.ssh/known_hosts.old "Aviso: Adicionou permanentemente a chave do host do ECDSA para o endereço IP 'x.x.x.x' à lista de hosts conhecidos." é exibido. e então parece funcionar - Wolfgang Fahl
Você pode atualizar a chave em vez de removê-la. Usar ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts depois disso, você não precisa verificar a nova chave na primeira conexão ao host. - Alex
Para quem não conseguir fazer isso funcionar: registrei múltiplas ocorrências do mesmo IP: 1 / o referido endereço IP (xx.xx.xx.xx), domínio (tomsihap.fr), servidor vps fornecido pelo provedor endereço (vpsxxx.ovh.net). ssh-keygen -R para cada um deles fez o trabalho. - tomsihap
Trabalhou para mim, mas a confusão pode ser de qual host esse comando deve ser executado? A resposta é da que exibiu o erro. A segunda pergunta e resposta são mais óbvias, mas apenas no caso: qual endereço passar para ssh-keygen -R? O endereço que figura na declaração de erro. - Russ Bateman


No meu caso ssh-keygen -R ... não consertou o aviso. Eu tinha informações extras assim:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Eu simplesmente editei manualmente ~/.ssh/known_hosts e excluiu a linha 8 (a "chave incorreta"). Eu tentei reconectar, o host foi adicionado permanentemente, e tudo estava bem depois disso!


40



Isso funcionou para mim. Obrigado! - Organic Marble
Funciona como um encanto. Pode consertar isso em uma linha com sed -e '8d' /home/myuser/.ssh/known_hosts, substituindo o número da linha 8 e o nome do arquivo com aqueles exibidos em seu sistema. - Alex P. Miller


Eu faço muito ssh-ing entre meus computadores de LAN e minhas duas contas de webhosting, então eu classifico todos os tipos de probabilidades e termina com SSH, incluindo problemas de autenticação usando ssh -v para ver onde e o que deu errado.

Tendo resolvido esse problema e não estando feliz com as respostas, eu queria realmente saber "por que" eu mesmo ...

O gatilho para o meu caso é: instalado o novo SO do servidor no trabalho e ao instalar o pacote openssh-server, um novo conjunto de chaves do host foi gerado no servidor do trabalho. Anteriormente, todos os sistemas operacionais do meu servidor eram o Ubuntu e desta vez ele mudou para o Debian (e eu suspeito que existe uma diferença sutil nas permissões).

Quando todos os sistemas operacionais eram Ubuntu e eu reinstalava o sistema operacional de um servidor, no primeiro SSH, recebi esse tipo de aviso, que prefiro acima do aviso silencioso acima!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Então eu abro ~ / .ssh / known_hosts no computador iniciando o ssh, apague essa linha, reconecte e isso acontece:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Esse bit aproximadamente: 11122 é o número da porta que eu rotear o SSH no firewall

Eu verifiquei backups de um antigo servidor Ubuntu e fiz uma diferença com a minha nova instalação Debian:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Então sim, provavelmente, o host começou a usar as chaves ecdsa recentemente, que com base nas alterações do Ubuntu recentemente, eu iria culpar uma atualização. A mudança do Ubuntu para longe do sistema operacional linux sólido, com o qual eu contava, é por que eu instalei o Debian desta vez.

Eu li um segurança.SE q / a no ecdsa e já removi essa linha de sshd_config meu novo servidor Debian. (e correu service ssh restart)


14



+1 para o bom bloco de comparação lado-a-lado. Você poderia adicionar uma URL esclarecendo que "a mudança do Ubuntu para longe do sistema operacional linux sólido" significa? - bgoodr
@bgoodr é a minha opinião e baseia-se unicamente na criação do meu próprio servidor de arquivos RAID várias vezes nos últimos anos. : / Porcaria de resposta, mas comece googling ubuntu debian server e você verá o que quero dizer. - Chris K
@ChrisK Você, senhor, é um chefe. Obrigado pela resposta detalhada, mas concisa. - sargas


ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Isso deve substituir as chaves existentes em known_hosts.old e criar uma nova. Essa solução funcionou para mim no mesmo cenário


5





O aviso ocorre toda vez porque os endereços IP mudam o tempo todo ao usar o endereçamento dinâmico. Tente usar o IP estático, para que você só precise adicionar a chave apenas uma vez.


4



Bom ponto, eu senti falta de alguém que mencionou ips dinâmicos? - Chris K


Você está usando o mesmo usuário para se conectar?

Se você está logado em um PC local como usuário John e conectado ao servidor B como usuário Adolf @ B e tudo está OK, isso não significa que tudo está OK se você estiver logado no PC local como usuário Jane e conectando-se ao servidor B como usuário Adolf @ B.

Se você quiser fazer o login no servidor B como usuário Beda do PC UMA sem senha, tente este comando, tudo a partir do PC UMA:

ssh-keygen -t rsa

Este comando gera a chave e armazena a chave no arquivo. Por favor saia passphrase vazio.

ssh Beda@B mkdir -p .ssh

Este comando cria o diretório, se eles ainda não existirem. Caso contrário, não imprima uma mensagem de erro.

cd ~/.ssh

Esse comando altera o diretório para o diretório inicial de usuários ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Este comando imprime o arquivo id_rsa.pub (sua chave pública) em authorized_keys no servidor.

IMPORTANTE: Beda é o seu nome de usuário no servidor que você está conectando, B é o seu servidor IP.

Agora, você pode se conectar ao servidor B sem uma senha ou frase secreta:

ssh Beda@B

2





O segmento Aqui pode ajudar.

Essencialmente, você deseja remover as chaves RSA e ECDSA para esse host e, em seguida, usar ssh-keyscan para colocá-los de volta em seu known_hosts arquivo de uma forma que não causará este conflito. Funcionou para mim quando tive o mesmo problema.


1





Pergunta: O que está causando isso, ...?

Então a chave do host do servidor ssh mudou. O que causou a mudança? É difícil dizer. Aqui estão algumas suposições:

  • O sshd no myserver começou a usar chaves ECDSA, então é um novo tipo de chave?
  • O myserver foi recentemente reinstalado?
  • O sshd no myserver foi recentemente reinserido para que uma nova chave de host ssh fosse gerada?
  • Alguém regenerou ou substituiu a chave do host sshd?
  • O endereço IP do myserver foi alterado para que um host diferente esteja respondendo a esse endereço IP?

Pergunta: ... e como faço para corrigir isso?

Como outros já responderam, remova a chave do host ECDSA em cache para o myserver que sua conta armazenou em cache.


1



Bom conselho, mas na verdade não responde a pergunta. Nem tenta responder a pergunta. - boatcoder


Este erro continuou me irritando por um longo tempo. Por alguma razão, fez a diferença se eu faria uma

ssh host

ou

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

Em seguida, apontei-me para a opção de alterar o arquivo de configuração. Veja meu roteiro https://askubuntu.com/a/949731/129227 lá para automatizar o processo.


1