Remova a chave armazenada em cache para 192.168.1.123 na máquina local:
ssh-keygen -R 192.168.1.123
Estou tentando configurar o SSH sem senha em um servidor Ubuntu com ssh-copy-id myuser@myserver , mas estou recebendo o erro:
Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'
O que está causando isso e como corrigi-lo? Eu tentei excluir o diretório .ssh na máquina remota e executar ssh-keygen -R "myserver" localmente, mas isso não resolve o erro.
No meu caso, ssh-keygen -R ... não corrigiu 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 excluí a linha 8 (a "chave incorreta"). Eu tentei reconectar, o host foi adicionado permanentemente, e tudo estava bem depois disso!
Eu faço muito ssh-ing entre meus computadores de LAN e minhas duas contas de webhosting, então eu classifiquei 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 acabado de resolver esse problema e não estar satisfeito 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, apago essa linha, reconecto 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 na qual eu rotear o SSH no firewall
Eu verifiquei os backups de um antigo servidor Ubuntu e fiz a diferença com a minha nova instalação do 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 culpava 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 uma segurança.SE q / a no ecdsa e já removi essa linha de sshd_config my new Servidor Debian. (e correu service ssh restart )
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
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, então você só precisa adicionar a chave apenas uma vez.
Você está usando o mesmo usuário para se conectar?
Se você estiver logado em um PC local como o usuário John e conectado ao servidor B como o usuário Adolf @ B e tudo estiver OK , isso não significa que tudo está OK se você estiver logado no PC local como o usuário Jane e se conectar ao servidor B como o usuário Adolf @ B .
Se você quiser fazer o login no servidor B como usuário Beda do PC A sem senha, tente este comando, tudo a partir do PC A :
ssh-keygen -t rsa
Este comando gera a chave e armazena a chave no arquivo. Por favor, deixe 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
Este comando altera o diretório para o diretório inicial do usuário ./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 IP do seu servidor.
Agora, você pode se conectar ao servidor B sem uma senha ou frase secreta:
ssh Beda@B
O tópico aqui pode ajudar.
Essencialmente, você deseja remover as chaves RSA e ECDSA para esse host e, em seguida, usar ssh-keyscan para colocá-las de volta no arquivo known_hosts de uma forma que não cause esse conflito. Funcionou para mim quando tive o mesmo problema.
Pergunta: O que está causando isso, ...?
Portanto, a chave do host do servidor ssh foi alterada. O que causou a mudança? É difícil dizer. Aqui estão algumas suposições:
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.
Eu consertei isso em um Chromebook desinstalando e reinstalando o Secure Shell ... Funcionou como um encanto.
Veja como remover uma impressão digital do host conhecida (do arquivo known_hosts ) em um sistema operacional do Google Chrome:
Encontre o índice da entrada do host incorreto na saída ssh quando a conexão falhar. Por exemplo, na linha abaixo do índice ofensivo está 7 :
Offending ECDSA key in /.ssh/known_hosts:7
Abra o console JavaScript ( CTRL + Desloca + J ) da janela Secure Shell e digite o seguinte, substituindo INDEX pelo valor apropriado (por exemplo, 7 ):
term_.command.removeKnownHostByIndex(INDEX);
Esta solução foi emprestada do Blog de Leo Gaggl .
Eu adicionei as seguintes linhas ao meu ~ / .ssh / config, desabilitando assim a verificação estrita do host para todos os endereços .local. (com a alocação de endereços DHCP, os endereços IP das minhas máquinas locais estão sempre mudando)
host *.local
StrictHostKeyChecking no
Você ainda recebe o aviso, o que é bom para mim.
Tags ssh security ssh-keys ubuntu-server