Existe-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$
REMARQUE:
.. par quelques réponses/commentaires, je me rends compte que ma question est un peu trompeuse, si courte qu'elle est comportement attendu), donc c'est normal (dans mon cas) il y a un raison valable derrière pourquoi je veux voir "l'ignorer")
Vous pouvez utiliser ssh -o StrictHostKeyChecking=no
pour désactiver la vérification known_hosts
momentanément. Mais je déconseille cela. Vous devriez vraiment vérifier pourquoi la clé d'hôte a changé.
Une autre option consiste à ajouter une entrée spécifique à votre ~/.ssh/config
pour l'hôte en question. Cela peut être une approche valide si vous avez un certain hôte qui génère de nouvelles clés d'hôte à chaque redémarrage et qu'il est redémarré plusieurs fois par jour pour une raison valable.
Host <your problematic Host>
StrictHostKeyChecking no
Pour ignorer complètement votre fichier d'hôtes connu dans un environnement POSIX, définissez les options GlobalKnownHostsFile
et UserKnownHostsFile
sur /dev/null
:
ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@Host
Réglage du 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 vaut probablement mieux s'attaquer au problème sous-jacent. Vous pouvez envisager authentification par certificat SSH pour vérifier les hôtes, par exemple.
Si vous avez réinstallé le serveur et donc que l'identification a changé, vous devez simplement supprimer la ligne spécifiée 155 de /Users/alexus/.ssh/known_hosts
et allez-y.
Si vous basculez entre différents réseaux privés, vous devez utiliser des noms d'hôtes pour vous connecter à la place, car le client ssh enregistrera également les clés en fonction du nom d'hôte. Ajoutez quelque chose comme ça à votre /etc/hosts
:
10.52.11.171 server1
10.52.11.171 server2
puis utilisez ssh server1
lorsqu'il est connecté au sous-réseau 1 et ssh server2
lorsqu'il est connecté à subnet2. De cette façon, les deux serveurs peuvent avoir des clés d'hôte différentes.
Certaines personnes disent que ce n'est pas bien, vous ne devez pas le faire et ainsi de suite, mais j'en ai également besoin pour tester plusieurs appareils intégrés encore et encore. Vous devez désactiver StrictHostKeyChecking=no
, c'est exact, mais réinitialisez également le fichier des hôtes connus sur /dev/null
. Voici un exemple avec connexion automatique et ps
sur un périphérique distant.
sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@Host 'ps ax'
-o StrictHostKeyChecking=no
ne fonctionne que si l'hôte n'est pas déjà présent dans le fichier known_hosts.
Je pense que c'est plus propre (pas d'avertissement), si vous vous attendez à ce que la clé des hôtes change, peut-être en raison du clonage vm, pour forcer 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"