"Ajouter la clé hôte correcte dans known_hosts" / plusieurs clés hôte SSH par nom d'hôte?

Je ne vois pas pourquoi vous voulez travailler avec deux clés, mais vous pouvez certainement ajouter plus d'une clé valide au fichier ~/.ssh/known_hosts, mais vous devrez le faire manuellement.

Une autre solution pourrait être d'utiliser l'option StrictHostKeyChecking=no pour cet hôte spécifique:

ssh -o StrictHostKeyChecking=no user@host

que vous pourriez mettre dans un alias dans votre fichier ~/.profile ou quelque chose de similaire.

alias hc=ssh -o StrictHostKeyChecking=no user@host

Si vous ne vous connectez qu'en SSH sur un réseau local alors...

Une solution simple est de supprimer l'ancien fichier de clé et de le remplacer par un fichier vide. Cela vous permettra de réautoriser toutes vos connexions avec de nouvelles clés. Si vous avez des clés ssh stockées pour des sites en dehors de votre réseau local, alors vous devez vous assurer que votre connexion initiale est sûre comme vous l'avez fait la première fois que vous vous êtes connecté à ce serveur.

par exemple

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Ensuite appuyez sur espace, effacer cntl+x et 'y' pour enregistrer le nouveau tampon (fichier). C'est une mauvaise pratique mais correcte tant que vous ne vous connectez pas régulièrement en dehors de votre réseau local (par exemple un serveur universitaire ou de travail)

Sur un réseau local sécurisé, c'est sûr parce que vous ne pouvez tout simplement pas subir d'attaque de l'homme du milieu.

Il vaut toujours mieux utiliser un code que vous comprenez !

Tant de réponses, mais tellement de gens abandonnent la protection en désactivant complètement la vérification stricte de l'hôte, ou en détruisant des informations d'hôte non liées ou en forçant simplement l'utilisateur à accepter les clés de manière interactive, éventuellement à un moment ultérieur, quand cela est inattendu.

Voici une technique simple qui vous permet de laisser la vérification stricte de l'hôte activée, mais de mettre à jour la clé de manière contrôlée, lorsque vous vous y attendez à ce qu'elle change:

• Supprimez l'ancienne clé et mettez à jour en une seule commande

  ssh-keygen -R server.example.com && \
      ssh -o StrictHostKeyChecking=no server.example.com echo Clé d'hôte SSH mise à jour.

• Répétez avec les adresses IP ou autres noms d'hôte si vous les utilisez.

L'avantage de cette approche est qu'elle recrée la clé du serveur exactement une fois. La plupart des versions de ssh-keygen semblent ne pas renvoyer d'erreur si le serveur que vous essayez de supprimer n'existe pas dans le fichier known_hosts, si cela pose un problème pour vous, utilisez les deux commandes en séquence.

Cette approche vérifie également la connectivité et émet un message clair pour les journaux dans la commande ssh (qui se connecte, met à jour la clé d'hôte et affiche Clé d'hôte SSH mise à jour puis se termine immédiatement.

Si votre version de ssh-keygen renvoie un code de sortie non nul, et que vous préférez gérer cela sans erreur, quelle que soit la connexion précédente, utilisez simplement les deux commandes en séquence, en ignorant toute erreur sur la commande ssh-keygen.

Si vous utilisez cette technique, vous n'avez jamais besoin de modifier votre commande ssh, ou de désactiver la vérification de l'hôte sauf pendant cette commande ssh spécifique. Vous pouvez être sûr que les futures sessions ssh fonctionneront sans conflit ni besoin d'accepter explicitement une nouvelle clé, tant que la commande ssh ci-dessus s'est exécutée sans erreur.

Vous devez supprimer l'ancienne clé du serveur client

ssh-keygen -R 192.168.0.25 #1ère suppression sur le serveur client

puis générer à nouveau la clé

ssh -o HostKeyAlias=192.168.0.25 root@192.168.0.25 #sur le serveur client

vérifiez que la nouvelle ligne est là

nano ~/.ssh/known_hosts

J'ai eu le même problème.

Tout ce que j'ai fait était sudo nano /home/user/.ssh/ host_allow et j'ai effacé la clé.

Quand je me suis reconnecté au serveur en ssh, il a ajouté une nouvelle clé.