87 votes

Ignorer temporairement mon fichier `~/.ssh/known_hosts` ?

Y a-t-il un moyen d'ignorer temporairement mon ~/.ssh/known_hosts fichier ?

mbp:~ alexus$ ssh 10.52.11.171
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /Users/alexus/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/alexus/.ssh/known_hosts:155
RSA host key for 10.52.11.171 has changed and you have requested strict checking.
Host key verification failed.
mbp:~ alexus$ 

NOTE :

par quelques réponse(s)/commentaires, je me rends compte que ma question est un peu trompeuse, donc la voici en résumé comportement attendu), donc c'est normal (dans mon cas) il y a une raison valable derrière cela pour laquelle je veux voir "ignorez-le")

0 votes

Pourquoi ce comportement est-il attendu ?

16 votes

Je ne peux pas parler pour l'utilisateur, mais un exemple serait une situation où vous développez un processus d'installation automatisé (tel qu'un kickstart), où votre flux de travail itératif implique la construction, la connexion, les tests, la modification du processus de construction et la reconstruction à partir de zéro, encore et encore.

19 votes

@MichaelHampton - J'ai ce problème tout le temps car VMware et VirtualBox recyclent les adresses IP pour les invités. Pour moi, c'est la bonne question :)

100voto

Vous pouvez utiliser ssh -o StrictHostKeyChecking=no pour désactiver la vérification known_hosts momentanément. Mais je vous le déconseille. Vous devriez vraiment vérifier pourquoi la clé de l'hôte a changé.

Une autre option est d'ajouter une entrée spécifique à votre ~/.ssh/config pour l'hôte en question. Cette approche peut être valable si vous avez un certain hôte qui génère de nouvelles clés d'hôte chaque fois qu'il redémarre et qu'il est redémarré pour une raison valable plusieurs fois par jour.

Host <your problematic host>
  StrictHostKeyChecking no

0 votes

C'est un comportement attendu) donc c'est normal (dans mon cas)

1 votes

@alexus Si c'est "attendu", alors vous pouvez appliquer l'option à un nom d'hôte/IP spécifique pour lequel vous attendez que cela se produise.

2 votes

@alexus Et rappelez-vous que si vous faites cela, vous perdez pratiquement toute la protection que ssh fournit. Vous pouvez tout aussi bien utiliser telnet, car il serait trivial pour quelqu'un de vous MITM et de capturer tout votre trafic.

64voto

MattB Points 756

Pour ignorer complètement votre fichier d'hôtes connus dans un environnement POSIX, définissez le paramètre GlobalKnownHostsFile y UserKnownHostsFile options pour /dev/null :

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@host

Fixer le StrictHostKeyChecking=no L'option vous permettra de vous connecter mais SSH affichera toujours un avertissement :

ssh -o StrictHostKeyChecking=no user@host

Comme d'autres l'ont fait remarquer, il est probablement préférable de s'attaquer au problème sous-jacent. Vous pourriez envisager Authentification par certificat SSH pour vérifier les hôtes, par exemple.

3 votes

Cela peut être une meilleure réponse que la réponse actuelle celui qui a été le plus voté parce qu'il permet d'utiliser l'authentification par mot de passe qui serait désactivée autrement (bien sûr, vous devez comprendre ce que vous faites exactement avant de taper votre mot de passe...)

1 votes

Je suis un peu confus ici : ne devriez-vous pas également utiliser -o StrictHostKeyChecking=no en plus de その -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null pour une réponse finale de.. : ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host ?

0 votes

Article connexe que j'ai trouvé en ligne : shellhacks.com/disable-ssh-host-key-checking

5voto

etagenklo Points 5599

Si vous avez réinstallé le serveur et que, par conséquent, l'identification a été modifiée, vous devez simplement supprimer la ligne 155 spécifiée dans le fichier /Users/alexus/.ssh/known_hosts et allez-y.

Si vous passez d'un réseau privé à un autre, vous devriez plutôt utiliser les noms d'hôte pour vous connecter, car le client ssh enregistrera également les clés en fonction du nom d'hôte. Ajoutez quelque chose comme ceci à votre /etc/hosts :

10.52.11.171 server1
10.52.11.171 server2

et ensuite utiliser ssh server1 lorsqu'il est connecté au sous-réseau 1 et ssh server2 lorsqu'il est connecté au sous-réseau 2. De cette façon, les deux serveurs peuvent avoir des clés d'hôte différentes.

0 votes

Que se passe-t-il si vous passez d'un réseau privé à un autre et que vous vous connectez à deux mêmes IP ?

1 votes

J'ai modifié ma réponse.

2 votes

@alexus Alors vous avez besoin d'IPv6 :) Mais cela aurait été une information utile dans votre question initiale.

4voto

eddso Points 41

Certaines personnes disent que ce n'est pas bien, qu'il ne faut pas faire ça et ainsi de suite, mais j'en ai aussi besoin pour tester plusieurs fois quelques dispositifs embarqués. Vous devez désactiver StrictHostKeyChecking=no c'est bien, mais il faut aussi réinitialiser le fichier d'hôtes connus à /dev/null . Voici un exemple avec autologin et ps sur le périphérique distant.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host 'ps ax'

3voto

Jose Sa Points 31

-o StrictHostKeyChecking=no ne fonctionne que si l'hôte n'est pas déjà présent dans le fichier known_hosts.

Je pense qu'il est plus propre (pas d'avertissement), si vous vous attendez à ce que la clé des hôtes change, peut-être à cause du clonage de vm, d'imposer l'ignorance de ce type d'hôtes comme ceci :

# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
    ssh-keygen -R ${host_ip}
    echo ${host_key} >>  ~/.ssh/known_hosts
}

# connect as normal way
ssh root@${host_ip} "hostname"

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X