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

Solution 1 :

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 valable 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é pour une raison valable plusieurs fois par jour.

Host <your problematic host>
  StrictHostKeyChecking no

Solution 2 :

Pour ignorer complètement votre fichier d'hôtes connu dans un environnement POSIX, définissez le GlobalKnownHostsFile et UserKnownHostsFile options à /dev/null :

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null [email protected]

Réglage du StrictHostKeyChecking=no l'option vous permettra de vous connecter mais SSH affichera toujours un avertissement :

ssh -o StrictHostKeyChecking=no [email protected]

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

Solution 3 :

Si vous avez réinstallé le serveur et donc 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ôte 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é au sous-réseau2. De cette façon, les deux serveurs peuvent avoir des clés d'hôte différentes.

Solution 4 :

-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'avertissements), 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 celui-ci :

# 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 [email protected]${host_ip} "hostname"

Solution 5 :

Certaines personnes disent que ce n'est pas correct, vous ne devez pas faire cela, etc., mais j'en ai également besoin pour tester plusieurs appareils intégrés encore et encore. Vous devez désactiver StrictHostKeyChecking=no , c'est vrai, mais réinitialisez également le fichier des hôtes connus sur /dev/null . Voici un exemple avec autologin et ps sur l'appareil distant.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected] 'ps ax'