Forcer ssh à ne pas imprimer l'avertissement «L'identification de l'hôte distant a changé»

24

Existe-t-il un moyen d'éviter l'impression ssh de messages d'avertissement comme celui-ci?

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

Bien que l'identité de l'hôte distant ait changé, mais je sais que ça va et je veux juste me débarrasser de cet avertissement.

ssh

— coffeMug
source

16

Quatre façons:

Pour vous connecter une seule fois à un système avec une nouvelle clé d'hôte, sans avoir à répondre à des questions, connectez-vous avec l'option suivante:

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

Pour supprimer définitivement l'avertissement pour tous les systèmes, modifiez votre ~/.ssh/configfichier pour ajouter les lignes suivantes:

Host *
StrictHostKeyChecking no

Pour supprimer définitivement tous les avertissements de ce un serveur, modifiez votre ~/.ssh/configfichier et ajoutez les lignes suivantes:

Host this.one.hostname
StrictHostKeyChecking no

Pour supprimer l'avertissement de cette modification pour ce serveur, supprimez la clé d'hôte de ce serveur ~/.ssh/known_hosts. La prochaine fois que vous vous connecterez, la nouvelle clé d'hôte sera ajoutée.

— Jenny D
source

Dans la deuxième option, cette configuration doit être effectuée côté serveur auquel nous nous connectons, n'est-ce pas?

— coffeMug

Non, c'est la vôtre $HOME/.ssh/configqui compte dans la deuxième et la troisième option.

— Jenny D

Cela affiche toujours un avertissement pour moi (bien qu'il autorise la connexion).

— Michael Mior

25

Ajoutez ceci à votre ~ / .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
source

3

MOD UP - un seul qui a réellement répondu à la question - c'était la seule réponse pour non seulement travailler, mais SUPPRIMER les AVERTISSEMENTS.

— Brad

Oups, il semble que les utilisateurs de fish shell ne pourront pas utiliser la belle autocomplétion ssh pour les hôtes précédemment connectés s'ils mettent UserKnownHostFile dans / dev / null. Les utilisateurs de poisson et peut-être tout le monde ne devraient pas régler cela.

— Elijah Lynn

Vous feriez mieux de créer un ssh0script / alias / fonction ssh -o UserKnowHostsFile=/dev/null -o LogLevel=ERRORet de l'utiliser expressément au lieu de vider ces options dans ~/.ssh/config. Vous pouvez les oublier et vous demander ensuite pourquoi les chèques n'ont pas fonctionné alors que vous vouliez simplement qu'ils fonctionnent.

— Oncle Billy

20

Vous pouvez retirer la ligne de cet hôte ~/.ssh/known_host (chaque hôte a une ligne comme entrée).

L'alternative est d'utiliser:

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

Une simple utilisation -qaurait sshéchoué en silence.

— Timo
source

9

Il est parfois souhaitable de ne pas ajouter de clés d'hôte aux $ HOME / .ssh / known_hosts par défaut.

À utiliser -o UserKnownHostsFile=/dev/nullen plus -qet -o StrictHostKeyChecking=nopour garder les hôtes_s connus épurés. Voici un exemple:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -q user@scripts.local

— Gars intelligent
source

2

Une autre suggestion consiste à identifier la raison pour laquelle la clé d'hôte change et à l'arrêter.

Par exemple: si vous créez des hôtes dans des conteneurs ou via un système de provisioning, assurez-vous qu'ils utilisent systématiquement la même clé d'hôte connue par instance.

Je sais bien que ce n'est pas toujours possible, et les hôtes peuvent être gérés en dehors de votre champ de contrôle, mais ces avertissements de clé d'hôte sont là pour une raison et sont importants. Réduire le nombre d'exceptions est une bonne chose.

Sinon, je vote pour StrictHostKeyChecking Non dans votre ~/.ssh/config pour l'hôte spécifique en question uniquement.

— Dr Edward Morbius
source