git-clé hôte du serveur non mise en cache

J'essaie de pousser les changements de mon repo local vers un repo distant. Quand je tape:

git push origin

Je reçois 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 résoudre cela? J'utilise git à partir de la ligne de commande dans Windows 7.

Modifier

Quand j'essaie de faire un simple ssh

ssh user@hostname

Je reçois 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ésoudre ce problème?

@eckes: Edit2

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

94
demandé sur snv 2011-02-08 12:31:08

15 réponses

Le message signifie que la clé hôte de origin n'est pas présente dans votre fichier d'hôtes de confiance.

Pour contourner ce problème, ouvrez une connexion SSH simple à {[1] } et SSH vous demandera si vous voulez 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 type yes), SSH ajoutera sa clé à la liste des hôtes connus.

Après cela, vous devriez être capable de faire votre git push origin.

, Comme alternative, vous pouvez également ajouter manuellement la clé de origin à .ssh/known_hosts mais cela nécessite que vous respectiez le format du fichier known_hosts tel que décrit dans la page de manuel de sshd (Section AUTHORIZED_KEYS format de fichier ).

52
répondu eckes 2018-02-14 16:09:26

Pour ceux d'entre vous qui configurez MSYS git sur Windows en utilisant PuTTY via L'invite de commande standard, la façon d'ajouter un hôte au cache de PuTTY est d'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 le reste.

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

146
répondu Roman Starkov 2015-05-12 17:26:26

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 set:

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 cela,.. Je suppose que putty enregistre ses clés ailleurs comme $HOME/.ssh ou quelque chose... (J'ai aussi eu un problème sur une boîte où $HOME a été défini sur "C:\Users\usrnam" au lieu de "/ C / Users / usrnam / "

Quoi qu'il en soit, votre kilométrage peut varier, mais cela l'a fixé pour moi. :-)

(probablement juste faire l'unset GIT_SSH est suffisant, mais j'étais sur un rouleau)

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

set GIT_SSH=
72
répondu Thijs 2015-08-06 10:37:25

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

Si c'est réellement votre cas, et que 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 obtenir 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 devrait être tous ensemble. Allez-y et essayez votre poussée à nouveau.

17
répondu Gunee 2013-04-01 21:40:06

Juste ssh'ING à l'hôte ne suffit pas, sur Windows au moins. Cela ajoute la clé hôte à ssh/known_hosts mais 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.

4
répondu andynormancx 2012-02-03 18:54:45

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

2
répondu rezsa f 2012-07-11 16:54:02

A eu le même problème, et oublier de Se connecter à SSH sur le port où est actuall repository , pas seulement le port SSH général, alors la clé hôte est différente!

2
répondu Mateusz 2013-08-22 10:19:42

Environnement de Travail:

  • Windows 10
  • git
  • mastic

Tout D'abord: Supprimer putty known_hosts dans registy selon le Regedit.
Ensuite: L'exécution de la commande %GIT_SSH% user@hostname dans le cmd de la fenêtre résout le problème.

J'espère que cela vous aidera tous.

2
répondu Jason 徐 2017-06-01 09:29:09

Solution avec Plink

Enregistrer ce script python à 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 pour le domaine (j'ai eu mes problèmes avec bitbucket), puis le script python le convertira au format Plink.

1
répondu Henrik 2012-08-23 15:29:08

Moi aussi, j'ai 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'entre eux travaillaient pour moi.

Ce qui a fonctionné pour moi était d'exécuter le programme Pageant (agent d'authentification Putty). Une fois que le concours était en cours d'exécution en arrière-plan, j'ai pu cloner, pousser et tirer de/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 nécessaire et le concours démarre.

1
répondu sunilkumarba 2014-02-12 14:00:53

Ouvrez simplement Putty et essayez d'établir une connexion au serveur distant que vous voulez pousser votre code. lorsque la boîte de dialogue apparaît, appuyez sur Oui (vous faites confiance à distance), tout serait OK.

1
répondu sadegh saati 2015-02-02 06:34:00

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

Il vous suffit de passer à Git intégré, de pousser, d'appuyer sur le bouton Oui, puis de revenir à System Git.

Vous pouvez trouver cette option dans

Tools -> Options -> Git
1
répondu Pyro 2015-12-16 12:59:59

Changer de PuTTY à OpenSSH a corrigé ce problème pour moi, sans avoir besoin de désactiver GIT_SSH, etc.

0
répondu 79E09796 2015-03-10 12:08:22

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

0
répondu Bart VdA 2016-06-01 10:50:35

J'ai essayé toutes les méthodes ci-dessus, mais aucun d'eux ne pouvait résoudre le même problème sur mon ordinateur portable. Enfin, au lieu de pousser la branche à origin dans Git bash, Je trun pour utiliser L'option push de TortoiseGit pour faire la poussée, puis une fenêtre apparaît pour me demander d'ajouter la nouvelle clé hôte au cache, après avoir cliqué sur le bouton Oui, tout va bien maintenant.

J'espère que cela vous aidera tous.

0
répondu Allen Jin 2017-01-10 02:40:20