Forçar o ssh a não imprimir o aviso "Identificação remota do host foi alterada"

23

Existe uma maneira de evitar mensagens de aviso de impressão ssh como esta? 

"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r",
"@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @\r",
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\r",

Embora a identidade do host remoto tenha mudado, eu sei que está tudo bem e só quero me livrar desse aviso.

ssh coffeMug
fonte

Respostas:

16

Quatro maneiras:

Para conectar apenas uma vez a um sistema com uma nova chave de host, sem precisar responder a perguntas, conecte-se com a seguinte opção:

ssh -q -o "StrictHostKeyChecking no" this.one.host.name

Para remover permanentemente o aviso para todos os sistemas, edite seu ~/.ssh/configarquivo para adicionar as seguintes linhas:

Host *
StrictHostKeyChecking no

Para remover permanentemente todos os avisos para este um servidor, editar o seu ~/.ssh/configarquivo e adicione as seguintes linhas:

Host this.one.hostname
StrictHostKeyChecking no

Para remover o aviso dessa alteração para esse servidor, remova a chave do host desse servidor ~/.ssh/known_hosts. Na próxima vez que você se conectar, a nova chave do host será adicionada.

Jenny D
fonte
Na segunda opção, essa configuração deve ser feita no lado do servidor ao qual estamos conectando, certo?
precisa saber é o seguinte
Não, é você $HOME/.ssh/configquem importa na segunda e na terceira opção.
Jenny D
Isso ainda imprime um aviso para mim (embora permita a conexão).
Michael Mior
24

Adicione isso ao seu ~ / .ssh / config:

Host 10.*                            # use your own pattern here, eg. *.example.com, example.*.com
  StrictHostKeyChecking   no         # turn off the HostKey check                                                               
  LogLevel                ERROR      # keep it from printing to STDOUT
  UserKnownHostsFile      /dev/null  # (optional) add the host automatically to a black hole, otherwise it would be added to ~/.ssh/known_hosts and show you a warning/message at the top of your session. You may want it added to known_hosts if your shell uses `ssh` autocompletion, such as fish.
Elijah Lynn
fonte
3
MOD UP - único que realmente respondeu à pergunta - esta foi a única resposta não apenas para o trabalho, mas para suprimir os avisos.
21317 Brad
Opa, parece que os usuários do shell de peixes não poderão usar o bom preenchimento automático de ssh para hosts conectados anteriormente se colocarem UserKnownHostFile em / dev / null. Usuários de peixe e possivelmente todos não devem definir isso.
Elias Lynn
É melhor criar um ssh0script / alias / função ssh -o UserKnowHostsFile=/dev/null -o LogLevel=ERRORe usá-lo expressamente em vez de despejar essas opções ~/.ssh/config. Você pode esquecê-las e depois se perguntar por que as verificações não funcionaram quando você só queria que elas funcionassem.
Tio Billy
20

Você pode retirar a linha desse host ~/.ssh/known_host(todo host tem uma linha como entrada).

Alternativa é usar:

ssh -q -o "StrictHostKeyChecking no" ....

Basta usar -qteria sshfalhar silenciosamente.

Timo
fonte
9

Às vezes, não é necessário adicionar chaves de host ao $ HOME / .ssh / known_hosts padrão.

Use -o UserKnownHostsFile=/dev/nullalém de -qe -o StrictHostKeyChecking=nopara manter o conhecimento_ organizado de maneira organizada. Aqui está um exemplo:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -q [email protected]
Cara inteligente
fonte
2

Uma sugestão alternativa é identificar por que a chave do host está sendo alterada e parar com isso.

Como exemplo: se você estiver construindo hosts em contêineres ou através de um sistema de provisionamento, verifique se eles usam consistentemente a mesma chave de host conhecida por instância.

Estou ciente de que isso nem sempre é possível, e os hosts podem ser gerenciados fora do seu escopo de controle, mas esses avisos de chave do host existem por um motivo e são significativos. Reduzir a contagem de exceções é uma coisa boa.

Caso contrário, voto no StrictHostKeyChecking No no seu ~/.ssh/config somente para o host específico em questão.

Dr. Edward Morbius
fonte