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.
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
?~/.ssh/known_hosts
? (Est-il répertorié 5000 fois?)~/.ssh/config
Existe- t- il / contient-il quelque chose (en particulier une valeur pourStrictHostKeyChecking
)?known_hosts
fichier 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.Réponses:
Solution: créez un
~/.ssh/config
fichier et insérez la ligne: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_hosts
fichier. 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.
la source
~
in~/.ssh/config
est le dossier de départ de l'utilisateur. Pour l'ouvrir facilement, appuyez sur Win-R , tapezcmd
Entrée . L'invite de commande devrait déjà s'ouvrir dans votre dossier de départ. Tapezcd .ssh
Entrée , puisstart .
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 (commegit fetch
), et vous avez terminé.Ajoutez la ligne suivante à votre fichier de configuration ssh ($ HOME / .ssh / config):
Si vous exécutez ssh à partir de la ligne de commande, ajoutez l'option suivante à la chaîne de commande:
Par exemple, ce qui suit imprime la version gcc installée sur machine.example.org (et aucun avertissement):
la source
LogLevel=quiet
est 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/null
commeknown_hosts
fichier, probablement parce qu'il voulait désactiver laknown_hosts
vérification des empreintes digitales, mais ne pouvait pas, parce que les seigneurs ssh ne le lui permettaient pas.loglevel=error
affiche toujours "Connexion au <serveur> fermée" lorsque la connexion est terminée, ce qui est également très ennuyeux pour les scripts.Définissez
LogLevel
surERROR
(pasQUIET
) dans le~/.ssh/config
fichier pour éviter de voir ces erreurs:la source
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.
la source
~/.ssh/known_hosts
et voyez si votre hôte est là-dedans.ssh-keyscan
.Pour supprimer les messages d'avertissement,
ssh
vous pouvez ajouter les lignes suivantes à~/.ssh/config
:Cela désactivera les avertissements mais pas les messages d'erreur. Comme les autres paramètres de,
~/.ssh/config
vous pouvez configurer leLogLevel
sur une base par hôte si vous voulez un contrôle plus fin.la source
Cela signifie principalement qu'il y a des changements pour la clé de cet hôte
~/.ssh/known_hosts
et 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_hosts
fichier 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
Ça fonctionne bien pour moi
la source
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:
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.
la source
J'ai la même question et j'ai trouvé qu'il n'y avait pas de
.ssh
fichier dans mon~
. Je crée donc simplement le.ssh
répertoire sous le~
chemin et le problème est résolu.la source
J'ai eu le même problème lorsque j'ai commencé à utiliser une machine Windows. Dans mon cas, c'était parce que ma configuration SSH n'était pas terminée. Github a une documentation très précise sur la configuration SSH. Une fois que cela a été réglé, le problème a été résolu.
https://help.github.com/articles/checking-for-existing-ssh-keys/ https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it- à-l'agent-ssh /
la source
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
ajouter ci-dessous la ligne.
Ajoutez ensuite la clé pub et clonez votre référentiel ... Terminé .....
la source
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.
la source
Dans mon cas, c'est parce que l'administrateur qui a configuré le serveur a défini ces options dans
~/.ssh/config
Ce qui a bien fonctionné dans la plupart des cas en n'utilisant pas le
~/.ssh/known_hosts
fichier. 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/null
ligne, 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>
la source
ajoutez votre clé privée à l'agent ssh avec:
la source
Dans mon cas, je n'ai reçu l'avertissement ssh que lors de l'utilisation de
qrsh
la connexion au shell distant Gridengine . Alors qu'une normalessh
fonctionnerait comme prévu (avertissement la première fois, puis calme les fois suivantes).Ma solution était de remplir manuellement
~/.ssh/known_hosts
tous les noms de serveurs possibles que Gridengine pouvait choisir (utiliserqhost
pour 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
qrsh
semblent toujours spécifier un port non standard pour faire la connexion ssh, provoquantknown_hosts
une mise à jour avec une entrée contenant également un numéro de port. La prochaine fois queqrsh
sélectionnerait le même serveur, il y aurait un nouveau numéro de port etknown_hosts
serait 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éeecdsa-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.
la source
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)
la source