Estou tentando configurar o SSH sem senha em um servidor Ubuntu 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 corrigi-lo? Tentei excluir o .sshdiretório na máquina remota e executar ssh-keygen -R "myserver"localmente, mas isso não resolve o erro.
Respostas:
Remova a chave 192.168.1.123em cache da máquina local:
ssh-keygen -R 192.168.1.123
ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsdepois que você não precisa verificar a nova chave na primeira conexão ao host.
No meu caso ssh-keygen -R ..., não consertei o aviso. Eu tinha informações extras como esta:
Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24
Simplesmente editei ~/.ssh/known_hostse excluí manualmente a linha 8 (a "chave incorreta"). Tentei reconectar, o host foi adicionado permanentemente e tudo ficou bem depois disso!
sed -e '8d' /home/myuser/.ssh/known_hosts, substituindo o número da linha 8e o nome do arquivo pelos exibidos no seu sistema.
known_hosts:8refere a um valor indexado a zero ou não. É bom saber que é um mapeamento 1: 1 ...
ssh-keygen -R [hostname]:2022
~/.ssh/known_hosts, recebo a mensagem de que a autenticidade não pode ser estabelecida e "Tem certeza de que deseja continuar se conectando". Responder "sim" tenta e falha na conexão. Se eu tentar conectar pela segunda vez, recebo o mesmo erro de chave do host ECDSA com o qual comecei.
Eu faço varreduras entre meus computadores da LAN e minhas duas contas de hospedagem na web, então resolvi todos os tipos de probabilidades e termina com o SSH, incluindo problemas de autenticação usando ssh -vpara 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" ...
O gatilho para o meu caso é: instalação do novo sistema operacional do servidor no trabalho e após a instalação do 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 Ubuntu e, desta vez, foram alterados para o Debian (e eu suspeito que haja uma diferença diferenciada nas permissões).
Quando todos os sistemas operacionais eram Ubuntu e eu reinstala o sistema operacional de um servidor, no primeiro SSH nele, recebo esse tipo de aviso, que eu prefiro sobre o 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_hostsno computador iniciando o ssh, excluo 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 pouco sobre: 11122 é o número da porta da qual eu direciono o SSH no firewall
Eu verifiquei os backups de um antigo servidor Ubuntu e fiz uma comparação 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 chaves ecdsa recentemente, que com base nas alterações do Ubuntu recentemente, eu culparia uma atualização. A mudança do Ubuntu para o SO Linux sólido como o qual eu contei é por que instalei o Debian desta vez.
Eu li um security.SE q / a no ecdsa e já removi essa linha do sshd_configmeu novo servidor Debian. (e correu service ssh restart)
ubuntu debian servere você verá o que quero dizer.
O prompt ocorre sempre, porque os endereços IP mudam o tempo todo ao usar o endereçamento dinâmico. Tente usar o IP estático para adicionar a chave apenas uma vez.
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. Esta solução funcionou para mim no mesmo cenário
Adicionei as seguintes linhas ao meu ~ / .ssh / config, desabilitando assim a verificação estrita do host para todos os endereços .local. (com alocação de endereço 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.
Você está usando o mesmo usuário para se conectar?
Se você estiver conectado a 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 estará bem se você estiver conectado ao PC local como o usuário Jane e se conectando ao servidor B como usuário Adolf @ B .
Se você deseja efetuar login no servidor B como usuário Beda do PC A sem senha, tente este comando, todos do PC A :
ssh-keygen -t rsa
Este comando gera a chave e armazena a chave no arquivo. Deixe a senha vazia.
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 allowed_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 senha:
ssh Beda@B
A discussão aqui pode ajudar.
Essencialmente, você deseja remover as chaves RSA e ECDSA desse host e usá ssh-keyscan-las para colocá-las novamente em seu known_hostsarquivo de uma maneira 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 mudou. O que causou a mudança? É difícil dizer. Aqui estão alguns palpites:
Pergunta: ... e como faço para corrigi-lo?
Como outras pessoas já responderam, remova a chave do host ECDSA em cache do myserver que sua conta armazenou em cache.
Esse erro me incomodou por muito tempo. Por alguma razão, fez 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
então me indicou a opção de alterar o arquivo de configuração. Veja meu script https://askubuntu.com/a/949731/129227 lá para automatizar o processo.
CanonicalizeHostnamee CanonicalDomainsevitaria a remoção de verificação rigorosa e faria ssh considerar host e host.domain para ser mesmo.
Corrigi isso em um Chromebook desinstalando e reinstalando o Secure Shell ... Funcionou como um encanto.
Veja como remover uma impressão digital de host conhecida (do known_hostsarquivo) em um Chrome OS:
Encontre o índice da entrada do host incorreto na saída ssh quando a conexão falhar. Por exemplo, na linha abaixo do índice incorreto é 7 :
Offending ECDSA key in /.ssh/known_hosts:7
Abra o console JavaScript ( CTRL+ Shift+ J) da janela Secure Shell e digite o seguinte, substituindo INDEXpelo valor apropriado (por exemplo, 7 ):
term_.command.removeKnownHostByIndex(INDEX);
The ECDSA host key for server has changed. Meu caminho é remover a seqüência de cache relacionada ao domínio em~/.ssh/known_hosts. Então o ssh funciona.