git - Clé d'hôte du serveur non mise en cache

101

J'essaie de transférer les modifications de mon dépôt local vers un dépôt distant. Quand je tape:

git push origin

J'obtiens l'erreur suivante:

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Connection abandoned.
fatal: The remote end hung up unexpectedly

Comment puis-je resoudre ceci? J'utilise git à partir de la ligne de commande dans Windows 7.

Éditer

Quand j'essaye de faire un simple ssh

ssh user@hostname

J'obtiens l'erreur suivante:

Could not create directory '/c//%HOMEDRIVE%%HOMEPATH%/.ssh'.
percent_expand: unknown key %H

D'une manière ou d'une autre, il ne créera pas le répertoire, car le chemin n'est pas valide. Comment régler ceci?

@eckes: Edit2

Ma maison est définie sur %HOMEDRIVE%%HOMEPATH%Est-ce correct?

René Terstegen
la source
2
On dirait que $HOMEn'est pas configuré correctement. Essayez de définir la HOMEvariable d'environnement sur Windows en utilisant My Computer-> clic droit -> Properties-> Tab Advanced-> ButtonEnvironment Variables
eckes
1
Je ne suis pas un gars de Windows, mais cela me semble étrange qu'après /c//(probablement une lettre de lecteur) vous ayez encore %HOMEDRIVE%... Vous pourriez peut-être vous faire gagner du temps en jouant vous-même avec la valeur et en la faisant écho?
Cascabel
1
Développer HOMEDRIVEet HOMEPATHdéfinir HOMEla valeur résultante ...
eckes

Réponses:

54

Le message signifie que la clé d'hôte de originn'est pas présente dans votre fichier d'hôtes approuvés.

Pour contourner cela, ouvrez une connexion SSH simple à originet SSH vous demandera si vous souhaitez faire confiance à l'hôte distant (à partir de la console Git):

$ ssh 127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is <FINGERPRINT>.
Are you sure you want to continue connecting (yes/no)?

Si vous faites confiance à l'hôte distant (c'est-à-dire le type yes), SSH ajoutera sa clé à la liste des hôtes connus.

Après cela, vous devriez pouvoir faire votre git push origin.

Comme alternative, vous pouvez également ajouter manuellement la clé de originà .ssh/known_hostsmais cela nécessite que vous respectiez le format du known_hostsfichier comme décrit dans la page de manuel de sshd(Section AUTHORIZED_KEYS FILE FORMAT ).

eckes
la source
4
J'ai reçu le même message lors d'un push vers github mais je peux ssh vers github et j'ai github.com dans mon known_hostsfichier.
Magnus Lindhe
1
Regardez la réponse ci-dessous dans ce cas
Nikita Koksharov
3
Vous pouvez utiliser PuTTY sur Windows aux mêmes fins, à la place d'un client SSH en ligne de commande.
brianmearns
1
Assurez-vous que les noms d'hôte sont exactement les mêmes. Par exemple, si vous avez installé git localement et utilisez le nom 'home.mydomain.com' comme télécommande, mais stockez la clé en utilisant putty pour vous connecter à 'localhost', cela ne fonctionnera pas. Vous devez vous connecter exactement au nom d'hôte dans votre URL distante.
Jason Goemaat
Pour moi fixe en essayant de se connecter avec du mastic au serveur. Disons que git url est ssh: //[email protected]: 222 / quelque chose / shop.git donc je suis entré dans le champ de nom d'hôte putty example.ex.com et le port 222. Ensuite, la connexion a échoué mais je suppose que cela a ajouté un doigt imprimez là où vous en avez besoin. Je ne comprends tout simplement pas où il a été ajouté car dans mon répertoire de base known_hosts - le fichier n'a pas été affecté lorsque j'ai supprimé l'ancienne clé
Darius.V
157

Pour ceux d'entre vous qui configurent MSYS Git sur Windows à l'aide de PuTTY via l'invite de commande standard, la façon d'ajouter un hôte au cache de PuTTY consiste à exécuter

> plink.exe <host>

Par exemple:

> plink.exe codebasehq.com

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 2e:db:b6:22:f7:bd:48:f6:da:72:bf:59:d7:75:d7:4e
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)

Répondez simplement y, puis Ctrl + C pour le reste.

Vérifiez cependant l'empreinte digitale. Cet avertissement est là pour une bonne raison. Empreintes digitales pour certains services git (veuillez modifier pour en ajouter plus):

Roman Starkov
la source
15
Cela devrait être la réponse acceptée. C'est précisément ce à quoi le message d'erreur fait référence. Dans mon cas, lorsque j'ai cloné, j'avais utilisé un FQDN, mais sur ma nouvelle machine, je ne m'étais connecté qu'en utilisant le nom de domaine local court. Je devais me connecter via putty ou plink en tant que FQDN pour mettre en cache la clé du nom d'hôte sur l'origine. Cela peut aider à vérifier le nom d'hôte utilisé comme distant en utilisant "git remote -v".
peabody
3
Cela fonctionne également pour utiliser PuTTY interactif avec l'hôte que vous essayez d'utiliser. Par exemple, si vous essayez de cloner un référentiel Github pour la première fois sur une nouvelle machine Windows, utilisez PuTTY pour ouvrir une session sur l'hôte 'github.com', acceptez l'invite concernant la confiance du serveur, puis un clone sur le la ligne de commande devrait fonctionner.
Jeremy McGee
1
Vous pouvez dire à MSYS que git tente d'utiliser plinken exécutant $ set | grep GIT_SSHet en vérifiantGIT_SSH='C:\Program Files (x86)\PuTTY\plink.exe'
shuckc
2
J'ai fini par résoudre ce problème en ajoutant ma clé à Pageant et en accédant directement à l'hôte avec Putty. Cela vous demande d'ajouter l'hôte au cache. Faire la même chose.
Knossos
1
Si votre dépôt git est servi sur un port SSH personnalisé, utilisez -Ppour sélectionner le port, tels que: plink.exe example.com -P 2222. J'ai pu cloner à partir de github mais pas à partir de mon serveur personnel, et cela m'a confus sans fin.
Hay
79

Essayez de faire un "set | grep -i ssh" à partir de l'invite Git Bash

Si votre configuration est comme la mienne, vous avez probablement ces ensembles:

GIT_SSH='C:\Program Files (x86)\PuTTY\plink.exe'
PLINK_PROTOCOL=ssh
SVN_SSH='"C:\\Program Files (x86)\\PuTTY\\plink.exe"'

j'ai fait un

unset GIT_SSH
unset PLINK_PROTOCOL
unset GIT_SVN

et cela a fonctionné après ça, .. Je suppose que putty enregistre ses clés ailleurs sous $ HOME / .ssh ou quelque chose comme ça ... (J'ai aussi eu un problème avec une boîte où $ HOME était réglé sur "C: \ Users \ usrnam "au lieu de" / C / Users / usrnam / "

de toute façon, votre kilométrage peut varier, mais cela a résolu le problème pour moi. :-)

(probablement juste faire le GIT_SSH unset est suffisant, mais j'étais sur une lancée)

Remarque: si unset ne fonctionne pas pour vous, essayez ceci:

set GIT_SSH=
Thijs
la source
1
"unset GIT_SSH" a fonctionné pour moi. J'avais précédemment configuré Pageant / putty pour un serveur différent, mais lorsque j'ai construit de nouvelles clés à l'aide de l'invite Git Bash, je devais revenir en arrière. Merci pour l'aide.
supermitch
après avoir franchi vos pas, je suis allé plus loin mais maintenant j'obtiens une erreur "mac currupted en entrée" ... déjà vu celui-là?
CD Smith
2
Lors de l'installation de git, vous pouvez choisir de NE PAS définir ces variables. C'est même la variante par défaut. Bien que j'aie choisi l'intégration plink aussi, c'est pourquoi je suis ici) Merci.
Antony Hatchkins
1
Cela a fonctionné pour moi aussi sur Win7. Apparemment, la configuration de git bash avec plink était à l'origine du problème dans mon cas.
nhylé
2
unset GIT_SSHa fonctionné pour moi aussi, même si je dois le faire à chaque fois que je lance git bash, ce qui est assez ennuyeux. Une idée sur la façon d'automatiser cela?
Loïc
19

Je soupçonne que votre GIT_SSHvariable d'environnement est définie sur %ProgramFiles(x86)%\putty\plink.exe. Pour une raison quelconque, PLink n'utilise pas le .ssh/known_hostsfichier de votre répertoire utilisateur pour stocker les clés des hôtes distants.

Si c'est réellement votre cas, et cela peut être exprès si vous voulez utiliser pageant, vous devez d'abord utiliser PLink pour vous connecter à l'hôte.

"$GIT_SSH" user@hostname

Vous devriez recevoir un message similaire

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)

Une fois que vous avez répondu yà la question et que vous vous êtes connecté avec succès à l'hôte distant, vous devriez être prêt. Allez-y et essayez à nouveau.

Gunee
la source
C'était tout pour moi en utilisant Git Bash sur Windows avec PLink / Pageant. Merci beaucoup!
amsross
1
En utilisant un référentiel Stash (maintenant Bitbucket), j'ai dû utiliser"$GIT_SSH" -P 7999 [email protected]
Julien
4

Se contenter de ssh'ing à l'hôte ne suffit pas, du moins sous Windows. Cela ajoute la clé d'hôte à ssh/known_hostsmais l'erreur persiste.

Vous devez fermer la fenêtre git bash et en ouvrir une nouvelle. Ensuite, le cache du registre est effacé et le push / pull fonctionne alors.

andynormancx
la source
ssh/known_hostsest relatif à quoi ?,% USERPROFILE% J'ai ce problème sur Win 7, et aucune solution ...
Frank Nocke
2

René, votre HOMEvariable n'est pas définie correctement. Changez-le en c:\Users\(your-username)ou simplement en %USERNAME%.

rezsa f
la source
2

Solution avec Plink

Enregistrez ce script python dans known_hosts.py:

#! /usr/bin/env python

# $Id$
# Convert OpenSSH known_hosts and known_hosts2 files to "new format" PuTTY
# host keys.
#   usage:
#     kh2reg.py [ --win ] known_hosts1 2 3 4 ... > hosts.reg
#       Creates a Windows .REG file (double-click to install).
#     kh2reg.py --unix    known_hosts1 2 3 4 ... > sshhostkeys
#       Creates data suitable for storing in ~/.putty/sshhostkeys (Unix).
# Line endings are someone else's problem as is traditional.
# Developed for Python 1.5.2.

import fileinput
import base64
import struct
import string
import re
import sys
import getopt

def winmungestr(s):
    "Duplicate of PuTTY's mungestr() in winstore.c:1.10 for Registry keys"
    candot = 0
    r = ""
    for c in s:
        if c in ' \*?%~' or ord(c)<ord(' ') or (c == '.' and not candot):
            r = r + ("%%%02X" % ord(c))
        else:
            r = r + c
        candot = 1
    return r

def strtolong(s):
    "Convert arbitrary-length big-endian binary data to a Python long"
    bytes = struct.unpack(">%luB" % len(s), s)
    return reduce ((lambda a, b: (long(a) << 8) + long(b)), bytes)

def longtohex(n):
    """Convert long int to lower-case hex.

    Ick, Python (at least in 1.5.2) doesn't appear to have a way to
    turn a long int into an unadorned hex string -- % gets upset if the
    number is too big, and raw hex() uses uppercase (sometimes), and
    adds unwanted "0x...L" around it."""

    plain=string.lower(re.match(r"0x([0-9A-Fa-f]*)l?$", hex(n), re.I).group(1))
    return "0x" + plain

output_type = 'windows'

try:
    optlist, args = getopt.getopt(sys.argv[1:], '', [ 'win', 'unix' ])
    if filter(lambda x: x[0] == '--unix', optlist):
        output_type = 'unix'
except getopt.error, e:
    sys.stderr.write(str(e) + "\n")
    sys.exit(1)

if output_type == 'windows':
    # Output REG file header.
    sys.stdout.write("""REGEDIT4

[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys]
""")

# Now process all known_hosts input.
for line in fileinput.input(args):

    try:
        # Remove leading/trailing whitespace (should zap CR and LF)
        line = string.strip (line)

        # Skip blanks and comments
        if line == '' or line[0] == '#':
            raise "Skipping input line"

        # Split line on spaces.
        fields = string.split (line, ' ')

        # Common fields
        hostpat = fields[0]
        magicnumbers = []   # placeholder
        keytype = ""        # placeholder

        # Grotty heuristic to distinguish known_hosts from known_hosts2:
        # is second field entirely decimal digits?
        if re.match (r"\d*$", fields[1]):

            # Treat as SSH-1-type host key.
            # Format: hostpat bits10 exp10 mod10 comment...
            # (PuTTY doesn't store the number of bits.)
            magicnumbers = map (long, fields[2:4])
            keytype = "rsa"

        else:

            # Treat as SSH-2-type host key.
            # Format: hostpat keytype keyblob64 comment...
            sshkeytype, blob = fields[1], base64.decodestring (fields[2])

            # 'blob' consists of a number of
            #   uint32    N (big-endian)
            #   uint8[N]  field_data
            subfields = []
            while blob:
                sizefmt = ">L"
                (size,) = struct.unpack (sizefmt, blob[0:4])
                size = int(size)   # req'd for slicage
                (data,) = struct.unpack (">%lus" % size, blob[4:size+4])
                subfields.append(data)
                blob = blob [struct.calcsize(sizefmt) + size : ]

            # The first field is keytype again, and the rest we can treat as
            # an opaque list of bignums (same numbers and order as stored
            # by PuTTY). (currently embedded keytype is ignored entirely)
            magicnumbers = map (strtolong, subfields[1:])

            # Translate key type into something PuTTY can use.
            if   sshkeytype == "ssh-rsa":   keytype = "rsa2"
            elif sshkeytype == "ssh-dss":   keytype = "dss"
            else:
                raise "Unknown SSH key type", sshkeytype

        # Now print out one line per host pattern, discarding wildcards.
        for host in string.split (hostpat, ','):
            if re.search (r"[*?!]", host):
                sys.stderr.write("Skipping wildcard host pattern '%s'\n"
                                 % host)
                continue
            elif re.match (r"\|", host):
                sys.stderr.write("Skipping hashed hostname '%s'\n" % host)
                continue
            else:
                m = re.match (r"\[([^]]*)\]:(\d*)$", host)
                if m:
                    (host, port) = m.group(1,2)
                    port = int(port)
                else:
                    port = 22
                # Slightly bizarre output key format: 'type@port:hostname'
                # XXX: does PuTTY do anything useful with literal IP[v4]s?
                key = keytype + ("@%d:%s" % (port, host))
                value = string.join (map (longtohex, magicnumbers), ',')
                if output_type == 'unix':
                    # Unix format.
                    sys.stdout.write('%s %s\n' % (key, value))
                else:
                    # Windows format.
                    # XXX: worry about double quotes?
                    sys.stdout.write("\"%s\"=\"%s\"\n"
                                     % (winmungestr(key), value))

    except "Unknown SSH key type", k:
        sys.stderr.write("Unknown SSH key type '%s', skipping\n" % k)
    except "Skipping input line":
        pass

Testé sur Win7x64 et Python 2.7 .

Puis exécutez:

ssh-keyscan -t rsa bitbucket.org >>~/.ssh/known_hosts
python --win known_hosts.py >known_hosts.reg
start known_hosts.reg

Et choisissez d'importer dans le registre. Le keyscan récupérera la clé publique du domaine (j'ai eu mes problèmes avec bitbucket), puis le script python la convertira au format Plink.

Henrik
la source
2

J'ai eu le même problème, et j'ai oublié de se connecter à SSH sur le port où se trouve le référentiel actuall , pas seulement le port SSH général, alors la clé d'hôte est différente!

Mateusz
la source
Utilisez également exactement la même manière de spécifier l'hôte, par exemple pas gitserver.example.com pour ssh et gitserver pour git.
Matthijs P
2

Ouvrez simplement Putty et essayez d'établir une connexion avec le serveur distant sur lequel vous souhaitez envoyer votre code. lorsque la boîte de dialogue apparaît, appuyez sur Oui (vous faites confiance à la télécommande), tout irait bien.

sadegh saati
la source
2

Environnement de travail:

  • Windows 10
  • git
  • mastic

Premièrement: Supprimez putty known_hosts dans le registre selon le Regedit.
Ensuite: L' exécution de la commande %GIT_SSH% user@hostnamedans la cmd de Windows résout le problème.

J'espère que cela vous aidera tous.

Jason 徐
la source
1

J'ai également eu le même problème lorsque j'essayais de cloner un référentiel sur ma machine Windows 7. J'ai essayé la plupart des réponses mentionnées ici. Aucun d'eux n'a fonctionné pour moi.

Ce qui a fonctionné pour moi, c'est d'exécuter le programme Pageant (Putty authentication agent). Une fois que le Pageant fonctionnait en arrière-plan, j'ai pu cloner, pousser et tirer depuis / vers le référentiel. Cela a fonctionné pour moi, peut-être parce que j'ai configuré ma clé publique de telle sorte que chaque fois qu'elle est utilisée pour la première fois, un mot de passe est requis et le Pageant démarre.

sunilkumarba
la source
Vous recevez un autre message d'erreur en cas de problème de reconstitution historique. Non Connection abandoned, mais quelque chose commeAccess denied (private key)
Andrey Regentov
1

Le passage de PuTTY à OpenSSH a résolu ce problème pour moi, sans avoir besoin de désactiver GIT_SSH, etc.

79E09796
la source
Si vous recevez le message concernant la clé d'hôte non reconnue pendant que vous effectuez des opérations push / pull git à l'aide de ATLASSIAN SOURCETREE, vous ne pouvez pas répondre y / n et l'opération push / pull sera abandonnée sans mettre la clé en cache. Cependant, aller à SourceTree Tools-> Options (onglet Général) et changer le client SSH sous (sous Configuration du client SSH) de PuTTY à OpenSSH permettra à la clé d'être mise en cache sans rien changer d'autre.
Rod Dewell le
1

J'ai résolu un problème similaire en utilisant cette solution de contournement .

Il vous suffit de passer à Embedded Git, d'appuyer sur, d'appuyer sur le bouton Oui, puis de revenir à System Git.

Vous pouvez trouver cette option dans

Tools -> Options -> Git
Pyro2266
la source
1
Maintenant sur l'emplacement v2.5.5.0:C:\Users\{UserName}\AppData\Local\SourceTree\app-2.5.5\tools\putty> .\plink.exe {YourNewHost}
John_J
1

Comme l'a répondu Roman Starkov ,plink faut ajouter l'hôte à son cache.

Pour les personnes utilisant les extensions Git :

  1. Ouvrir les extensions Git
  2. Allez dans Outils -> Paramètres -> SSH
  3. Copiez le chemin vers "plink.exe" (si vous utilisez PuTTY) / "klink.exe" (si vous utilisez KiTTY)
  4. Dans une console, exécutez la commande suivante:

(remplacer par les chemins réels)

<the path to plink/klink.exe> <address to the server>

par exemple

%ProgramData%\chocolatey\lib\kitty\tools\klink.exe codebasehq.com

Remarque : assurez-vous d'utiliser le même plink / klink que Git Extensions utilise!

Reyhn
la source
0

L'ajout de l'hôte directement avec Bash n'a pas résolu le problème, l'erreur se produisait toujours lors de l'utilisation de 'Extraire tout' dans les extensions Git. En utilisant 'Pull' sur une branche, l'hôte requis a été ajouté automatiquement par Git Extensions avec un écran contextuel Bash. Après avoir fait cela, j'ai pu utiliser à nouveau «Fetch All». Je ne sais pas ce qui est fait différemment par les extensions Git.

Bart VdA
la source
0

J'ai essayé toutes les méthodes ci-dessus, mais aucune d'entre elles n'a pu résoudre le même problème sur mon ordinateur portable. Enfin, au lieu de pousser la branche à l'origine dans git bash, je trun pour utiliser l'option push de TortoiseGit pour faire le push, puis une fenêtre apparaît pour me demander d'ajouter la nouvelle clé d'hôte au cache, après avoir cliqué sur le bouton oui, tout se passe bien maintenant.

J'espère que cela vous aidera tous.

Allen Jin
la source
0

J'ai changé un disque dur, installé Windows. Lorsque essayé de télécharger des fichiers a reçu cette fenêtre de commande.

J'ai appuyé sur "y", puis sur Ctrl + C. Ouvert putty.exe, ajouté une ancienne clé, retourné à git et poussé les fichiers.

CoolMind
la source
0

Désinstallez simplement les extensions Git et réinstallez-les en choisissant OpenSSH au lieu de

Kiran.vanam
la source
0

Dans Windows 7 ou 10, l'astuce qui a fonctionné pour moi est de supprimer la variable système GIT_SSH. Il était auparavant configuré pour utiliser Plink, et a maintenant été remplacé par Putty. Cela provoquait une erreur Plink.exe

Il y avait aussi une ancienne installation de Git (version 32 bits) et une mise à jour vers Git (par exemple Git-2.20.1-64-bit.exe) car le PC était un OS 64 bits.

Quoi qu'il en soit, Putty / Plink n'était même pas utilisé par Git puisque dans l'installation de Git, il était par défaut d'utiliser Open SSH.

DonAriston
la source
0

Si vous recevez le message concernant la clé d'hôte non reconnue pendant que vous effectuez des opérations push / pull git à l'aide de ATLASSIAN SOURCETREE, vous ne pouvez pas répondre y / n et l'opération push / pull sera abandonnée sans mettre la clé en cache. Cependant, aller à SourceTree Tools-> Options (onglet Général) et changer le client SSH sous (sous Configuration du client SSH) de PuTTY à OpenSSH permettra à la clé d'être mise en cache sans rien changer d'autre.

Rod Dewell
la source