SSH dans une boîte avec une IP fréquemment changée


22

J'ai des boîtes cloud qui changent fréquemment leur IP.

J'utilise ssh le nom d'hôte, mais je dois modifier le fichier known_hosts à chaque lancement du serveur en raison de ce message d'erreur:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is

Outre les risques de sécurité et ceux associés à ce que je veux faire, existe-t-il un moyen d'ignorer cette erreur ou d'écraser automatiquement le fichier known_hosts de sorte que je n'ai pas toujours à le modifier moi-même?

Réponses:


20

Editez votre fichier ssh_config et ajoutez changez cette ligne:

CheckHostIP no

La valeur par défaut de CheckHostIP est «oui». Ce que cela fait, c'est de faire exactement le genre de vérification que vous échouez. Si vous le désactivez, cela signifie simplement que l'IP est variable et qu'il fera une vérification des clés par rapport au nom d'hôte.


2
Cela désactive une fonction de sécurité pour tous les serveurs auxquels vous vous connecterez, ce qui est extrêmement mauvais. Vous devez à la place utiliser cette option uniquement pour un hôte spécifique que vous savez avoir ce problème - ou utiliser l'option HostKeyAlias ​​- à nouveau pour un hôte spécifique.
zaTricky

@zaTricky "Extrêmement mauvaise pratique"? Qu'est-ce qui est si extrême hmm? Je pense que c'est à peu près autant sécurisé, c'est simplement une préférence individuelle. Vous venez d'épingler une clé à un nom d'hôte (au lieu d'IP). Pour https, le HPKP fonctionne de manière similaire et tout le monde dit qu'il est soit sécurisé, soit trop sécurisé.
kubanczyk

@kubanczyk Cela dit d'en faire un cadre global - aucun conseil concernant la spécification d'un hôte, que j'ai
souligné

25

Addition: vous pouvez essayer de désactiver uniquement la vérification CheckHostIP pour ce nom:

Host *
  [ global settings .. ]

Host very.dynamic.host
  CheckHostIP no

5
Il s'agit de la meilleure option pour réduire l'impact sur la sécurité de la désactivation de la vérification IP.
Espo

3

Beaucoup de réponses ici fonctionneront - mais techniquement, ce sont des solutions de contournement. OpenSSH dispose déjà d' une fonctionnalité intégrée dans cet esprit: HostKeyAlias.


Dans votre fichier .ssh / config, ajoutez HostKeyAlias <alias>à une configuration d'hôte:

host myserver.example.com
HostKeyAlias myserver.example.com

Avec cela en place, la connexion au serveur myserver.example.comn'utilisera pas le nom d'hôte ou l'adresse IP pour la référence locale - elle n'utilisera toujours que HostKeyAlias ​​donné lors de la connexion à ce serveur. Pour moi, il est logique d'utiliser le nom d'hôte - mais vous pouvez bien sûr utiliser n'importe quel alias que vous aimez.


Les configurations typiques pour moi pour les hôtes dynamiques sont comme ceci:

host myserver
hostname myserver.dyn.example.com
HostKeyAlias myserver.private.example.com

Cela peut également être utilisé dans certains scénarios obscurs où vous savez qu'un groupe de vos serveurs ont les mêmes clés d'hôte (généralement cela ne devrait pas être le cas). Cela empêcherait alors les entrées en double. À l'avenir, si les clés changent légitimement, vous n'aurez pas à remplacer / supprimer plusieurs entrées. Seulement un. Les serveurs Gitlab Geo en sont un bon exemple.


En ce qui concerne la suppression du fichier known_hosts, je suggérerais de regarder d'autres questions / réponses spécifiquement liées à la maintenance / suppression des entrées périmées de unknown_hosts. Par exemple, voir Comment gérer mon fichier .ssh / known_hosts ; Je suis particulièrement impressionné par la réponse de user1953828, même si je vois qu'il n'a pas encore beaucoup de votes positifs. :)


Cela montre la valeur d'une réponse le jour même pour SO par rapport à la bonne réponse, répondue 8 ans plus tard.
parity3

2

J'utilise ces options douteuses pour contourner ce problème. (La clé publique de mon hôte est régénérée assez souvent. Cela supprime donc l'IP et la vérification des clés)

ssh remoteServerName -l username -o "UserKnownHostsFile=/dev/null"

Vous pouvez également simplement l'utiliser si la clé reste la même mais que l'IP change:

ssh remoteServerName -l username -o "CheckHostIP=no"

Si votre serveur change les clés d'hôte aussi souvent, vous devriez envisager de configurer la signature des clés d'hôte
Cameron Tacklind

1

Vous pouvez définir StrictHostKeyChecking = no dans votre ssh configuration de client (c'est-à-dire le fichier ~ / ssh / config sur la machine à partir de laquelle vous vous connectez) pour ignorer l'avertissement.


1

Vous pouvez mettre CheckHostIP nodans votre ~/.ssh/configfichier, mais cela vous laisse ouvert à des attaques d'usurpation. Si cela ne vous inquiète pas, ce paramètre devrait désactiver la known_hostsvérification.


0

J'évite d'ajouter les empreintes digitales à mon known_hostsfichier lors de la connexion à des machines AWS transitoires. J'utilise une commande telle que

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i secret.pem ec2-user@10.0.0.5

pour se connecter à eux. Il ne vous demandera pas si vous souhaitez ajouter la machine «à la liste des hôtes connus». Remplacez 10.0.0.5par l'adresse IP de votre machine et secret.pempar le chemin complet de votre clé Ssh. Vous recevrez toujours un avertissement indiquant que l' 10.0.0.5ajout a été ajouté, mais il a vraiment disparu /dev/null. Je le fais assez souvent pour définir un alias dans mon~/.profile

alias awsssh='ssh -i secret.pem -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

Je réserve ssh ec2-user@example.comdes commandes de type aux machines où je me suis donné la peine de vérifier l'empreinte digitale.


Cela est logique pour les serveurs que vous ne jamais se connecter à la fois - mais il y a de meilleures façons de se débarrasser des entrées obsolètes - et vous ne devriez pas être que préoccupé par la façon dont le fichier salir known_hosts est. Vous avez probablement passé beaucoup plus de temps et d'énergie à créer cet alias que la valeur que l'alias vous a apportée.
zaTricky

-2

Faites connaître_hosts en lecture seule.


Cela rompt la fonctionnalité lorsque des options pragmatiques sont facilement disponibles. : - /
zaTricky
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.