Git dit "Avertissement: ajouté de manière permanente à la liste des hôtes connus"

196

Chaque fois que j'utilise git pour interagir avec une télécommande, comme lorsque je tire ou pousse, le message suivant s'affiche:

Avertissement: Ajout permanent de «...» (RSA) à la liste des hôtes connus.

Comment puis-je empêcher ce message ennuyeux de s'afficher? Ce n'est qu'un ennui - tout fonctionne correctement.

Donald Taylor
la source
1
Voulez-vous vraiment dire à chaque fois? Cela vous donne-t-il une invite du formulaire The authenticity of host '...' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)?ou l'avez-vous supprimé? Si c'est le cas, s'agit-il de la même empreinte digitale à chaque fois? Si ce n'est pas le cas, c'est vraiment effrayant . L'option la moins effrayante serait que d'une manière ou d'une autre, il ne parvient pas à écrire dans le fichier hosts, donc il essaie à nouveau à chaque fois. Jetez un oeil à ~/.ssh/known_hosts?
Cascabel
1
Oui. <i> Chaque </i> fois. Cependant, je ne vois pas le message "Êtes-vous sûr ..." - je l'ai peut-être supprimé.
Donald Taylor
L'hôte est-il répertorié dans ~/.ssh/known_hosts? (Est-il répertorié 5000 fois?) ~/.ssh/configExiste- t- il / contient-il quelque chose (en particulier une valeur pour StrictHostKeyChecking)?
Cascabel
L'hôte est répertorié une fois dans ce fichier et c'est la seule entrée.
Donald Taylor
2
Je suppose que le contenu de votre known_hostsfichier est mauvais. Ce devrait être la clé de l'hôte, sur une très longue ligne. Si vous ne disposez que du nom d'hôte (par exemple), cela ne fonctionnera pas. Je vous recommande de supprimer ce fichier (si en effet il ne contient que les informations pour cet hôte unique) et d'autoriser SSH à le créer la prochaine fois que vous vous connectez. Il devrait rester silencieux après cela.
tripleee

Réponses:

243

Solution: créez un ~/.ssh/configfichier et insérez la ligne:

UserKnownHostsFile ~/.ssh/known_hosts

Vous verrez alors le message la prochaine fois que vous accéderez à Github, mais après cela, vous ne le verrez plus car l'hôte est ajouté au known_hostsfichier. Cela résout le problème, plutôt que de simplement masquer le message du journal.

Ce problème me dérangeait depuis un certain temps. Le problème se produit car le client OpenSSH compilé pour Windows ne vérifie pas le fichier known_hosts dans~/.ssh/known_hosts

ssh -vvvvvvvvvvvvvvvvvv [email protected]

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
Jérémie Gowdy
la source
9
Oui, je ne considère pas la suppression des avertissements ou des erreurs comme une solution appropriée à un problème. ;)
Jeremiah Gowdy
6
Fonctionne très bien! Finalement, l'avertissement stupide s'est arrêté. Btw sous Windows, le ~in ~/.ssh/configest le dossier de départ de l'utilisateur. Pour l'ouvrir facilement, appuyez sur Win-R , tapez cmd Entrée . L'invite de commande devrait déjà s'ouvrir dans votre dossier de départ. Tapez cd .ssh Entrée , puis start . Entrée pour ouvrir le dossier dans l'Explorateur Windows. Ensuite, vous pouvez créer le fichier de configuration dans le Bloc-notes (pas d' extension .txt lors de l'enregistrement). (Les utilisateurs Pro peuvent envoyer un écho directement à un nouveau fichier dans l'invite de commande elle-même ;)). Exécutez une commande git impliquant remote deux fois (comme git fetch), et vous avez terminé.
ADTC
2
pourquoi avez-vous 20 v pour ssh?
bubakazouba
4
@bubakazouba Plus il y a de v, plus le journal est détaillé, consultez la documentation pour cela. Trois suffiraient, vingt sont exagérés: D
Petr Mánek
2
Ouais, maintenir v pendant une seconde est plus rapide que de vérifier la documentation pour déterminer le nombre maximal de v utiles
Jeremiah Gowdy
90

Ajoutez la ligne suivante à votre fichier de configuration ssh ($ HOME / .ssh / config):

LogLevel=quiet

Si vous exécutez ssh à partir de la ligne de commande, ajoutez l'option suivante à la chaîne de commande:

-o LogLevel=quiet

Par exemple, ce qui suit imprime la version gcc installée sur machine.example.org (et aucun avertissement):

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -o LogLevel=quiet \
    -i identity_file \
    machine.example.org \
    gcc -dumpversion
Kyle Kloepper
la source
1
L'ajout de "LogLevel = quiet" au fichier "config" a fonctionné. Merci.
Donald Taylor
3
Pour maintenir la sécurité, il serait bon de mettre le "LogLevel = quiet" dans une section "Host".
Joe
41
LogLevel=quietest une mauvaise idée, il veut que toutes les erreurs soient affichées, il veut juste éviter cette erreur odieuse spécifique. Probablement parce qu'il a trompé ssh pour l'utiliser /dev/nullcomme known_hostsfichier, probablement parce qu'il voulait désactiver la known_hostsvérification des empreintes digitales, mais ne pouvait pas, parce que les seigneurs ssh ne le lui permettaient pas.
Elazar Leibovich
@bukzor loglevel=erroraffiche toujours "Connexion au <serveur> fermée" lorsque la connexion est terminée, ce qui est également très ennuyeux pour les scripts.
Guss
J'ai rejeté cela car cela ne résout pas vraiment le problème. Cela le cache simplement.
alaboudi
60

Définissez LogLevelsur ERROR(pas QUIET) dans le ~/.ssh/configfichier pour éviter de voir ces erreurs:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR
user1193229
la source
2
Cela a fonctionné mieux dans mon cas - ou vous pouvez spécifier "-oLogLevel = ERROR" sur la ligne de commande
Brad
5

Ce message provient de SSH, qui vous avertit que vous vous connectez à un hôte auquel vous ne vous êtes jamais connecté auparavant. Je ne recommanderais pas de le désactiver, car cela signifierait que vous pourriez manquer un avertissement concernant un changement de clé d'hôte, ce qui peut indiquer une attaque MITM sur votre session SSH.

Jason Carreiro
la source
1
Mais je me connecte dessus 10 à 15 fois par jour, et je reçois toujours cet avertissement.
Donald Taylor
@JackB. Regardez ~/.ssh/known_hostset voyez si votre hôte est là-dedans.
Borealid
La clé change-t-elle pour une raison quelconque? Vérifiez l'empreinte digitale dans le fichier par rapport à l'empreinte digitale sortie par ssh. De plus, le mode de votre répertoire .ssh est-il défini sur 0700?
Jason Carreiro
2
@JasonCarreiro, je suis un grand garçon, je sais que personne ne tirera d'attaque MITM dans mon rack, la sécurité est un compromis, et je veux que les nouveaux ordinateurs fonctionnent immédiatement avec une clé pré-partagée, sans avoir besoin de gérer une autorité de certification ou ssh-keyscan.
Elazar Leibovich
4

Pour supprimer les messages d'avertissement, sshvous pouvez ajouter les lignes suivantes à ~/.ssh/config:

Host *
LogLevel error

Cela désactivera les avertissements mais pas les messages d'erreur. Comme les autres paramètres de, ~/.ssh/configvous pouvez configurer le LogLevelsur une base par hôte si vous voulez un contrôle plus fin.

Stefan Schmidt
la source
2

Cela signifie principalement qu'il y a des changements pour la clé de cet hôte ~/.ssh/known_hostset qu'il ne la mettra pas automatiquement à jour. Par conséquent, chaque fois que vous recevez ce message d'avertissement.

Cela se produit souvent pour la connexion aux machines virtuelles recréées, ce qui change la clé avec la même adresse IP

Solution

Si vous n'avez qu'une seule entrée, vous pouvez supprimer le ~/.ssh/known_hostsfichier et, après la première connexion, que la clé sera là, et aucun message d'avertissement après cela.

Si vous avez plusieurs entrées, vous pouvez utiliser la commande ci-dessous pour supprimer

$ ssh-keygen -R <hostname>

Ça fonctionne bien pour moi

Larry Cai
la source
0

Si vous utilisez un référentiel de GitHub, envisagez d'utiliser la version HTTPS de l'URL à la place, pour éviter complètement ce problème:

Cliquez sur le bouton HTTP et clonez cette URL à la place

Si vous clonez votre référentiel à partir de l'application Windows GitHub, c'est ce qu'il utilise pour l'URL distante. Peut-être qu'ils savent quelque chose que nous ne savons pas.

Rachitisme
la source
Remarque: si vous utilisez l'authentification par clé privée, vous ne pouvez pas utiliser HTTP (S).
qwertzguy
0

J'ai la même question et j'ai trouvé qu'il n'y avait pas de .sshfichier dans mon ~. Je crée donc simplement le .sshrépertoire sous le ~chemin et le problème est résolu.

Kris Roofe
la source
0

Ajouter une clé ssh

ssh-keygen -t rsa -b 4096 -C "[email protected]"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/bitbucket_rsa

fichier de configuration de caisse

crate ~/.ssh/config

ajouter ci-dessous la ligne.

UserKnownHostsFile ~/.ssh/known_hosts

Ajoutez ensuite la clé pub et clonez votre référentiel ... Terminé .....

Thanuja
la source
0

J'avais rencontré la même erreur dans Linux / Cent OS VM et c'était parce que l'IP changeait après le redémarrage. Afin de contourner ce problème, j'ai défini une adresse IP statique dans le réseau et ajouté cette entrée au fichier / etc / hosts. Pour une adresse IP statique, indiquez une valeur de plage légèrement supérieure. Par exemple, si votre adresse IP actuelle (ipconfig / ifconfig) est 192.168.0.102, la prochaine fois après le redémarrage, cela peut devenir 192.168.0.103. Définissez donc votre adresse IP statique dans les paramètres IPV4 comme 192.168.0.181, ce qui devrait faire l'affaire.

Vignesh Menon
la source
essayez de mettre en évidence les mots-clés et d'être clair avec le format, cela vous aidera à atteindre votre réponse pour les autres
Agilanbu
0

Dans mon cas, c'est parce que l'administrateur qui a configuré le serveur a défini ces options dans ~/.ssh/config

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Ce qui a bien fonctionné dans la plupart des cas en n'utilisant pas le ~/.ssh/known_hostsfichier. Mais pour le dépôt gitlab d'entreprise, à chaque fois, il donnait le message "Avertissement: ajouté de manière permanente ... à la liste des hôtes connus."

Ma solution a été de commenter la UserKnownHostsFile /dev/nullligne, ce qui a permis la création de ~/.ssh/known_hosts. Ensuite, il n'a plus donné d'avertissement après cela.

Vous pouvez également avoir des entrées anciennes / invalides dans votre fichier known_hosts.

# find entry in ~/.ssh/known_hosts
ssh-keygen -F <hostname>

# delete entry in ~/.ssh/known_hosts
ssh-keygen -R <hostname>
wisbucky
la source
0

ajoutez votre clé privée à l'agent ssh avec:

ssh-add ~/.ssh/id_rsa
Cromerou
la source
0

Dans mon cas, je n'ai reçu l'avertissement ssh que lors de l'utilisation de qrshla connexion au shell distant Gridengine . Alors qu'une normale sshfonctionnerait comme prévu (avertissement la première fois, puis calme les fois suivantes).

Ma solution était de remplir manuellement ~/.ssh/known_hoststous les noms de serveurs possibles que Gridengine pouvait choisir (utiliser qhostpour lister les serveurs):

for p in server1 server2 server3 server4; do
  ssh-keyscan -H ${p}.company.com;
  ssh-keyscan -H $(getent hosts $p | perl -lane 'print $F[0]');
done >> ~/.ssh/known_hosts

Contexte:

Gridengine est un planificateur de travaux qui peut utiliser ssh pour sélectionner le serveur le moins chargé. La raison de l'avertissement est que qrshsemblent toujours spécifier un port non standard pour faire la connexion ssh, provoquant known_hostsune mise à jour avec une entrée contenant également un numéro de port. La prochaine fois que qrshsélectionnerait le même serveur, il y aurait un nouveau numéro de port et known_hostsserait mis à jour avec une nouvelle entrée spécifique au port. La raison de l'ajout de l'adresse IP brute de l'hôte est que certains hôtes l'ont utilisée ecdsa-sha2-nistp521. Si une entrée IP brute n'est pas ajoutée, j'obtiendrais l'avertissement:

ECDSA host key for IP address '10.1.2.3' not in list of known hosts.
Axel Bregnsbo
la source
-1

Il n'y a pas de solution propre au problème que vous avez noté pour autant que je sache.
La redirection / dev / null suggérée précédemment affichera toujours l'avertissement, elle désactive simplement la fonction de sécurité de stockage des clés distantes en redirigeant la sortie vers / dev / null.
Donc ssh penserait toujours qu'il écrit quelque chose qui est en fait écarté.

Comme je le sais, la seule option est d'attraper le message et de le supprimer de stdout.

ssh/scp..... 2>&1 | grep -v "^Warning: Permanently added"

Voici un exemple complet que vous pouvez utiliser comme wrapper pour masquer ces avertissements:

#!/bin/bash
remove="^Warning: Permanently added" # message to remove from output

cmd=${0##*/}

case $cmd in
 ssh)
  binary=/usr/bin/ssh
 ;;
 *)
  echo "unsupported binary ($0)"
  exit
 ;;
esac
$binary "$@" 2>&1 | grep -v "$remove"

Pour l'installer, tout ce que vous avez à faire est d'ajouter / modifier l'instruction "case" pour la commande que vous souhaitez modifier. (ssh, scp, git etc.).
le "ssh)" signifie que le script doit être nommé "ssh" (ou un lien vers le script est nommé ssh). Le binaire = / full / path est le chemin vers le binaire que le script doit encapsuler.
Ensuite, placez le script avec un nom de votre choix dans / bin ou ailleurs.

Le script est également l'endroit où vous pouvez utiliser un -o "UserKnownHostsFile = / dev / null" à la variable $ binaire, c'est bien mieux que de mettre un tel risque de sécurité dans la configuration globale ssh qui affectera toutes vos sessions ssh et non juste ceux dont vous voulez supprimer le message.

Inconvénients:
c'est un peu plus complexe, pas une solution parfaitement propre et déplace stderr dans stdout, ce qui peut ne pas être bon dans tous les cas.
Mais cela éliminera toutes sortes de messages d'avertissement que vous ne souhaitez pas voir et vous pouvez utiliser un seul script pour envelopper tous les binaires que vous voulez (en utilisant des liens de système de fichiers vers lui)

John
la source