ssh: a autenticidade do host 'hostname' não pode ser estabelecida

Quando ssh para uma máquina, às vezes recebo esse aviso de erro e ele solicita "sim" ou "não". Isso causa alguns problemas ao executar a partir de scripts que ssh automaticamente para outras máquinas.

Mensagem de aviso:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Existe uma maneira de dizer automaticamente "sim" ou ignorar isso?

Dependendo do seu cliente ssh, você pode definir a opção StrictHostKeyChecking como no na linha de comando e / ou enviar a chave para um arquivo null null_conhecidos. Você também pode definir essas opções no seu arquivo de configuração, para todos os hosts ou para um determinado conjunto de endereços IP ou nomes de host.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDITAR

Como observa o @IanDunn, há riscos de segurança em fazer isso. Se o recurso ao qual você está se conectando tiver sido falsificado por um invasor, ele poderá repetir o desafio do servidor de destino, enganando-o a pensar que você está se conectando ao recurso remoto enquanto na verdade ele está se conectando a esse recurso com suas credenciais. Você deve considerar cuidadosamente se esse é um risco apropriado a ser assumido antes de alterar seu mecanismo de conexão para ignorar o HostKeyChecking.

Referência .

Pergunta antiga que merece uma resposta melhor.

Você pode impedir o prompt interativo sem desativar StrictHostKeyChecking(o que não é seguro).

Incorpore a seguinte lógica ao seu script:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Ele verifica se a chave pública do servidor está inserida known_hosts. Caso contrário, ele solicita a chave pública do servidor e a adiciona known_hosts.

Dessa maneira, você estará exposto ao ataque Man-In-The-Middle apenas uma vez, o que pode ser mitigado por:

• garantindo que o script se conecte pela primeira vez em um canal seguro
• inspecionando logs ou known_hosts para verificar manualmente as impressões digitais (a serem feitas apenas uma vez)

Para desativar (ou controlar a desativação), adicione as seguintes linhas ao início de /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Opções:

• A sub-rede Host pode *permitir acesso irrestrito a todos os IPs.
• Edite /etc/ssh/ssh_configpara configuração global ou ~/.ssh/configpara configuração específica do usuário.

Consulte http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Pergunta semelhante em superuser.com - consulte https://superuser.com/a/628801/55163

Verifique se ~/.ssh/known_hostsé gravável. Isso consertou para mim.

A melhor maneira de fazer isso é usar 'BatchMode' além de 'StrictHostKeyChecking'. Dessa forma, seu script aceitará um novo nome de host e o gravará no arquivo known_hosts, mas não exigirá intervenção sim / não.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

Edite seu arquivo de configuração normalmente localizado em '~ / .ssh / config' e, no início do arquivo, adicione as linhas abaixo

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

O usuário definido como your_login_userdiz que essas configurações pertencem ao seu_login_user
StrictHostKeyChecking definido como não evitará o prompt
IdentityFile é o caminho para a chave RSA

Isso funciona para mim e meus scripts, boa sorte para você.

Este aviso é emitido devido aos recursos de segurança, não desative esse recurso.

É apenas exibido uma vez.

Se ele ainda aparecer após a segunda conexão, o problema provavelmente está ocorrendo por escrito no known_hostsarquivo. Nesse caso, você também receberá a seguinte mensagem:

Failed to add the host to the list of known hosts 

Você pode corrigi-lo alterando o proprietário, alterando as permissões do arquivo para que seja gravável pelo usuário.

sudo chown -v $USER ~/.ssh/known_hosts

Com referência à resposta de Cori, eu a modifiquei e usei o comando abaixo, que está funcionando. Sem exit, o comando restante estava realmente conectado à máquina remota, o que eu não queria no script

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

Faça isso -> chmod +w ~/.ssh/known_hosts. Isso adiciona permissão de gravação ao arquivo em ~/.ssh/known_hosts. Depois disso, o host remoto será adicionado ao known_hostsarquivo quando você se conectar a ele na próxima vez.

Idealmente, você deve criar uma autoridade de certificação autogerenciada. Comece gerando um par de chaves: ssh-keygen -f cert_signer

Em seguida, assine a chave do host público de cada servidor: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Isso gera uma chave de host pública assinada: /etc/ssh/ssh_host_rsa_key-cert.pub

Em /etc/ssh/sshd_config, aponte HostCertificatepara este arquivo: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Reinicie o serviço sshd: service sshd restart

Em seguida, no cliente SSH, adicione o seguinte a ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

O acima contém:

• @cert-authority
• O domínio *.example.com
• O conteúdo completo da chave pública cert_signer.pub

A cert_signerchave pública confiará em qualquer servidor cuja chave de host pública seja assinada pela cert_signerchave privada.

Embora isso exija uma configuração única no lado do cliente, você pode confiar em vários servidores, incluindo aqueles que ainda não foram provisionados (desde que você assine cada servidor).

Para mais detalhes, consulte esta página wiki .

Geralmente esse problema ocorre quando você está modificando as chaves com muita frequência. Com base no servidor, pode levar algum tempo para atualizar a nova chave que você gerou e colou no servidor. Portanto, depois de gerar a chave e colar no servidor, aguarde de 3 a 4 horas e tente. O problema deve ser resolvido. Isso aconteceu comigo.

Adicione-os ao seu / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Execute isso no servidor host, é problema de premonição

chmod -R 700 ~/.ssh

Eu tive o mesmo erro e queria chamar a atenção para o fato de que - como aconteceu comigo - você pode ter privilégios errados.
Você configurou seu .sshdiretório como regular ou como rootusuário e, portanto, precisa ser o usuário correto. Quando esse erro apareceu, eu estava, rootmas configurei .sshcomo usuário comum. Saindo rootcorrigido.

Resolvo o problema que fornece o erro escrito abaixo:
Erro:
Não é possível estabelecer a autenticidade do host 'XXX.XXX.XXX'.
A impressão digital da chave RSA é 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Solução:
1. instale qualquer ferramenta openSSH.
2. execute o comando ssh
3. pedirá para você adicionar este host como. aceite SIM.
4. Este host adicionará à lista de hosts conhecidos.
5. Agora você pode se conectar com este host.

Esta solução está funcionando agora ......