Question N'ajoutez pas d'hôte à known_hosts pour SSH


Je veux me connecter à un hôte via SSH mais je ne veux pas que le nom d’hôte soit ajouté à mon ~/.ssh/known_hosts.

Comment puis je faire ça?


93
2018-05-15 00:03


origine




Réponses:


Si vous souhaitez utiliser ce comportement car vous travaillez avec des serveurs cloud (AWS EC2, Rackspace CloudServers, etc.) ou que vous configurez constamment de nouvelles images dans Vagrant, vous pouvez mettre à jour votre configuration SSH au lieu d'ajouter des alias bash ou plus d'options. ligne de commande.

Pensez à ajouter quelque chose comme:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET
  • Utilisez aussi strict que regex pour que l'hôte puisse être sécurisé.
  • Mettre LogLevel sur QUIET conservera l’Avertissement mentionné par Guillaume

81
2018-06-07 00:28



Vous devriez vraiment essayer de ne pas désactiver complètement StrictHostKeyChecking, donc la réponse de cclark est un excellent compromis pour travailler avec des serveurs cloud. - Alex Recarey
Cela m'a été très utile car j'utilisais Shipit (un outil de déploiement JavaScript) contre Vagrant. Je ne pouvais pas facilement atteindre les paramètres que Shipit passait à SSH, cela m'a permis de contourner l'outil et de lui dire ce que je faisais et je ne voulais pas qu'il s'en souvienne. - John Munsch
LogLevel est ce que je cherchais. Il présente l'avantage supplémentaire de ne pas afficher l'avis configuré par la société lors de l'exécution de scripts! (Je cours maintenant avec ERREUR loglevel) - Anshu Prateek
Dans quel fichier est-ce que j'ajoute ceci? - Wim Deblauwe
Ceci est votre fichier de configuration SSH. Dans Linux ou MacOS, le fichier se trouve généralement dans un répertoire appelé .ssh dans votre répertoire personnel et nommé config - ~ / .ssh / config - cclark


-o "UserKnownHostsFile /dev/null"

devrait marcher.


75
2018-05-15 00:30



Fonctionne comme prévu, mais il signalera toujours: "Avertissement: ajout permanent de" nom d'hôte, ip "(RSA) à la liste des hôtes connus." J'ai fait ce qui va avec: 2> & 1 | grep -v "^Warning: Permanently added" - Guillaume Boudreau
C'est ce dont j'avais besoin pour mon scénario - pas de DNS, LAN avec DHCP, des ordinateurs obtenant des adresses différentes tout le temps. Je vais devoir taper «oui» tout le temps, mais sinon c'est génial. - Tomasz Gandor
ajouter -o "LogLevel ERROR" et il ne se plaindra plus avec les avertissements - John
Remarque: une demande de suppression de ce message "Avertissement: ajout permanent de 'hostname, ip' (RSA) à la liste des hôtes connus." a été signalé aux responsables bugzilla.mindrot.org/show_bug.cgi?id=2413 - Ben Creasy
Tuyauterie à grep fusionnera stdout et stderr; Le statut de sortie peut également changer. Si vous utilisez bash, il vaudra mieux utiliser la substitution de processus pour se débarrasser du message: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Cela évitera le pipe et donc les modifications correspondantes dans la gestion du statut de sortie. - Alex O


J'ai envie d'ajouter la clé de l'hôte à known_hosts (les personnes qui exécutent ces services sont, selon mon expérience, au moins assez intelligentes pour que leurs clés hôtes restent cohérentes entre les machines desservant le même nom d'hôte) et que StrictHostKeyChecking soit désactivé. Se connecter avec LogLevel ERROR vous offrira la meilleure expérience sans sacrifier la sécurité. (Ok, sans CheckHostIP, vous devez faire confiance au DNS, qui est un énorme trou béant sans DNSSEC répandu ou quelque chose de similaire, mais nous allons simplement balayer cela sous le tapis pour le moment.)

J'utilise un fichier know_hosts en lecture seule, je dois donc faire quelque chose ou recevoir des avertissements sans fin pour ne pas pouvoir ajouter d'entrées à known_hosts.

Ce que j'utilise:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Je voudrais que ces services publient leurs clés d’hôte SSH sur leurs sites Web via HTTPS, de sorte que je puisse les copier explicitement sans avoir à me connecter d’abord et éventuellement à une attaque MITM.


8
2018-05-20 17:40





je suggère

LogLevel ERROR

plus de

LogLevel QUIET

de sorte que vous obtenez toujours "Impossible de résoudre le nom d'hôte" et d'autres erreurs de ce type


4
2018-01-24 00:19



Vous devriez pouvoir faire confiance à vos connexions SSH. Ne vous contentez pas de faire taire vos risques. - sylvainulg
Dépend vraiment Nous avons des environnements de développement qui sont détruits chaque semaine et reconstruits, leurs enregistrements A restent les mêmes, mais leur clé hôte est générée à chaque fois qu’elle est construite. Nous ne pouvons pas conserver les clés d'hôte car l'enregistrement A est défini dans une base de données basée sur un nom d'environnement et les noms d'environnement peuvent être supprimés ou de nouveaux créés à tout moment. La solution ci-dessus est donc vraiment utile. - Alex Berry


Pour une seule session ssh, utilisez cette

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

3
2017-12-16 05:54



Cela n'ajoute rien de nouveau à une réponse acceptée sur une question datant de 5 ans. - JakeGould


Avez-vous essayé de désactiver StrictHostKeyChecking? Vous pouvez le faire avec le -o option ou dans le fichier de configuration ~/.ssh/config.


2
2018-05-15 00:11



J'utilise déjà ça. Mais cela a un effet différent: cela réduit la rigueur de la vérification de la clé de l'hôte. C'est à dire. Lorsque l'hôte est inconnu, il se connecte quand vous désactivez cette option. Ainsi, il sauve toujours l'hôte. Mais je pense avoir trouvé la bonne solution (voir ma réponse). - Albert


J'ai trouvé les entrées suivantes .ssh / config utiles (LAN avec DHCP et DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Le résultat correspond aux noms de machines locales "zora" ou "goron" ne vérifient pas les adresses IP attribuées dynamiquement, mais www.mycompany.com ou node42.planetlab.com auront toujours leurs adresses IP statiques confirmées.


0
2018-01-23 09:19