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


153

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?


27
Eu desaconselharia isso. Você precisa descobrir por que está recebendo esses erros, caso contrário, estará se abrindo para um homem no meio do ataque, do qual esses erros estão tentando protegê-lo.
Peter Bagnall

3
Isso pode ser causado por uma alteração no servidor usando essa chave ssh ou por alguém sentado entre você e o servidor ouvindo tudo o que você envia / recebe.
precisa saber é o seguinte

qual poderia ser a razão desse erro?
AIU

Eu discordo do ponto de vista de Peter. Em uma organização grande, tentar convencer alguém a resolver problemas assim quando você está apenas tentando concluir o seu trabalho não é realista.
Sridhar Sarnobat 14/11/19

Muitas organizações grandes são exatamente o oposto do que o @SridharSarnobat está sugerindo. Você precisa garantir que as pessoas certas resolvam esses tipos de problemas, e tentar contorná-las apenas piora as coisas.
James Moore

Respostas:


135

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 .


40
Acho irresponsável recomendar isso sem aviso sobre as implicações de segurança. superuser.com/a/421084/121091 é uma resposta melhor da IMO.
11136 Ian Dunn

5
@IanDunn Eu concordo com você em uma situação geral do cliente SSH, mas, como o OP afirma claramente que ele está enfrentando esse problema ao executar scripts, a alternativa é quebrá-lo toda vez que a chave do host é alterada (e há várias razões pelas quais pode ser esse o caso) que a resposta a que você se referiu não resolve. Dito isto, é uma crítica válida, por isso atualizei minha resposta para apontar o risco.
cori

6
Não acredito que muitas pessoas tenham votado positivamente nessa resposta e também que ela seja aceita pelo questionador. Essa abordagem ignora as verificações de segurança e a conecta ao host remoto. Verifique se o arquivo known_hosts na pasta ~ / .ssh / tem permissão de gravação. Se não, então use essa resposta stackoverflow.com/a/35045005/2809294
ARK

Contanto que você saiba o que está fazendo, esta é a melhor solução. Eu tenho um site interno ao qual nos conectamos automaticamente com MUITOS, atualizando endereços IP (efetivamente aleatórios). Eu adicionei isso ao ~ / .ssh / config e ele simplesmente funciona. Lembre-se, EU SEI que este site é o que eu acho que é e, se não for, os bandidos não têm vantagem, pois eu sei quais dados estão sendo transferidos.
user1683793 03/04

75

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)

4
Ou simplesmente gerencie o arquivo known_hosts para todas as máquinas como parte da sua configuração de infraestrutura.
Thilo

1
observe que o ssh-keyscan não funciona com o ProxyCommand: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv

1
não funcionará como esperado. `ssh-keygen -F $IP`Deve ser "`ssh-keygen -F $IP`"(entre aspas), em outro caso, não será interpretada como uma string
avtomaton

Ou como um oneliner usando o valor de retorno ssh-kegen:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

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


19

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


4
é seguro permitir que todos escrevam para known_hosts?
akaRem

2
@akaRem definitivamente não. Geralmente, você deseja que ele seja gravável apenas para o usuário que possui essa .sshpasta.
2rs2ts

as permissões 0400são ótimas (por favor, corrija-me alguém), no entanto, no meu caso, o problema era simplesmente que a .sshpasta do meu usuário tinha sua propriedade alterada, invalidando, portanto, minhas próprias permissões 0400. sudoalterar a propriedade de volta para mim resolveu meu problema.
Charney Kaye

Este corrigiu o problema para mim.
Sivaji 7/03

14

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"

10

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ê.


Obrigado, realmente salvou o dia. Mas qual é a última linha IdentityFile? Parece que funciona sem ele também ..
supersan

7

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

5

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"

5

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.


4

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 .


2

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.



0

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

chmod -R 700 ~/.ssh

você está pedindo às pessoas que alterem as permissões em keys_chave e chaves públicas de 644 para 700? E chave privada de 600 a 700?
Nurettin

0

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.


-3

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 ......


Isso não responde à pergunta. A pergunta original (muito antiga) era sobre a capacidade de confirmar automaticamente essas solicitações via script.
MasterAM

Se funcionou para ele, talvez funcione para outros. Não há necessidade de downvote algo que é realmente útil
Mbotet

executando "ssh" não está funcionando. Ele está mostrando para o uso opções: ssh [..] [..] [..] [user @] hostname [comando]
P Satish Patro
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.