É possível evitar a seguinte mensagem sobre: (REMOTE HOST IDENTIFICATION HAS CHANGED)
Ao usar apenas esta sintaxe de conexão
ssh xxx.xxx.xxx.xxx
exemplo de mensagem de aviso:
ssh 10.19.11.1 CentOS release 5.8 (Final) Kernel 2.6.18-308.el5 on an i686 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 dd:6f:32:8f:8f:8c:70:9c:95:f1:48:83:60:97:cc:ed. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:7 RSA host key for 10.19.11.1 has changed and you have requested strict checkin. Host key verification failed.
cada vez que recebo essas mensagens, limpo o /root/.ssh/known_hosts
como
cp /dev/null /root/.ssh/known_hosts
Eu também estava pensando em definir o comando cp / dev / null /root/.ssh/known_hosts no crontab,
para que todos os dias às 24:00 ele limpe o arquivo known_hosts (esta solução diminui o problema, mas não o resolve )
então esta solução não é tão boa porque o usuário pode obter a mensagem de aviso apesar de limparmos o arquivo known_hosts todo dia
talvez possamos fazer algo em / etc / ssh arquivo / ssh_config para evitar a verificação da chave do host SSH?
observação:
Não quero usar o método a seguir para pr evento a verificação da chave do host SSH (porque eu uso reflexão / massa)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]
Insisto em usar apenas esta sintaxe como
ssh xxx.xxx.xxx.xxx
para conexão
Comentários
- Simplificando: don ' t fazer isso. Você realmente leu esse aviso? Há um motivo para este aviso. E é para protegê-lo dos danos de um ataque MitM e de outras coisas ruins.
Resposta
Atualização: Atualmente você pode usar certificados SSH , semelhantes ao TLS certificados. Em seguida, você pode adicionar uma known_hosts
entrada para confiar no certificado em vez de nas chaves individuais, e você nunca receberá esta mensagem novamente.
Preste atenção ao @ 0xC0000022L “s aviso !
Se você sabe que a chave do host mudou , você pode remover essa entrada específica do known_hosts
arquivo:
ssh-keygen -R xxx.xxx.xxx.xxx
Isso é muito melhor do que substituir o todo arquivo hosts (que pode ser feito apenas com > /root/.ssh/known_hosts
).
Se você não quiser usar ssh
opções de linha de comando, acredito que a única outra maneira de fazer isso seria modificar o código SSH e recompilar. O que você realmente não quero fazer!
Comentários
- mas eu quero fazer isso de maneira automática, quando o usuário reclamar disso, eu não não quero fazê-lo manualmente
- Você não ' não quer fazê-lo manualmente (removin g
known_hosts
entradas) e você não ' quer fazê-lo automaticamente (usandossh
opções). Como você deseja fazer isso então? - @ l0b0 Fornecendo uma opção de linha de comando para suprimir o recurso. Em alguns ambientes, como ambientes de máquina virtual e outras configurações muito dinâmicas (especialmente ambientes de teste), essas chaves de host mudam com frequência e, como estão em uma rede isolada, há pouca segurança a ser obtida ao fazer a verificação. Ter que fazer um
ssh-keygen -R
toda vez é irritante. Suponho que alguém possa escrever um shell para ssh, um script de shell que analisa o endereço de destino e remove a chave antes de passar opções para o ssh, mas isso parece um exagero.
Resposta
etapa 1: remova a chave com falha
ssh-keygen -R 192.168.1.1
etapa 2: adicionar nova chave
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts
ou dependendo da sua situação
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts
Comentários
- -1 por fornecer uma arma de fogo sem aviso.
- @ l0b0 Muito bem, sua honra!
Resposta
Ao conectar-se a máquinas virtuais descartáveis ou semelhantes, é melhor não armazenar as chaves em primeiro lugar.
Crie um ssh0
alias ou função com o seguinte conteúdo:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR"
Dessa forma, você não “poluirá seu ~/.known_hosts
arquivo com lixo, e como você está usando um comando diferente, haveria um problema psicológico limite entre o ssh “real” e aquele usado para instrumentar algum widget local.
Outro apelido útil é
alias sshy="ssh -o CheckHostIP=no"
para quando você “está se conectando a um dispositivo que muda seu IP com frequência, como, por exemplo, um roteador doméstico ao qual o ISP atribui um IP diferente a cada vez que é desligado e religado.
Comentários
- Resposta perfeita para isso!