git: clave de host del servidor no almacenada en caché


101

Intento enviar cambios desde mi repositorio local a un repositorio remoto. Cuando escribo:

git push origin

Obtuve el siguiente error:

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

¿Como puedo resolver esto? Estoy usando git desde la línea de comando en Windows 7.

Editar

Cuando trato de hacer un ssh simple

ssh user@hostname

Obtuve el siguiente error:

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

De alguna manera no creará el directorio, porque la ruta no es válida. ¿Cómo arreglar esto?

@eckes: Edit2

Mi casa está configurada en %HOMEDRIVE%%HOMEPATH%¿esto es correcto?


2
Parece que $HOMEno está configurado correctamente. Intente configurar la HOMEvariable de entorno en Windows usando My Computer-> clic derecho -> Properties-> Tab Advanced-> BotónEnvironment Variables
eckes

1
No soy un tipo de Windows, pero me parece extraño que después de /c//(presumiblemente una letra de unidad) todavía tenga %HOMEDRIVE%... ¿Podría ahorrarse algo de tiempo jugando con el valor usted mismo y haciéndolo eco?
Cascabel

1
Expanda HOMEDRIVEy HOMEPATHestablezca HOMEel valor resultante ...
eckes

Respuestas:


54

El mensaje significa que la clave de host de originno está presente en su archivo de hosts de confianza.

Para evitar esto, abra una conexión SSH simple originy SSH le preguntará si desea confiar en el host remoto (desde la consola 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 confía en el host remoto (es decir, el tipo yes), SSH agregará su clave a la lista de hosts conocidos.

Después de eso, debería poder hacer su git push origin.

Como alternativa, también puede agregar manualmente la clave de origina, .ssh/known_hostspero esto requiere que se adhiera al formato del known_hostsarchivo como se describe en la página de manual de sshd(Sección AUTHORIZED_KEYS FILE FORMAT ).


4
Recibí el mismo mensaje al hacer un envío a github, pero puedo ssh a github y tengo github.com en mi known_hostsarchivo.
Magnus Lindhe

1
En este caso
Nikita Koksharov

3
Puede usar PuTTY en Windows para los mismos fines, en lugar de un cliente SSH de línea de comandos.
brianmearns

1
Asegúrese de que los nombres de host sean exactamente iguales. Por ejemplo, si tiene git instalado localmente y usa el nombre 'home.mydomain.com' como su control remoto, pero almacena la clave usando putty para conectarse a 'localhost', eso no funcionará. Necesita conectarse exactamente al nombre de host en su URL remota.
Jason Goemaat

Para mí, se solucionó el intento de conectarme con masilla al servidor. Digamos que git url es ssh: //git@example.ex.com: 222 / something / shop.git, así que entré en el campo de nombre de host de putty example.ex.com y el puerto 222. Luego, la conexión falló pero supongo que agregó el dedo imprimir donde sea necesario. Simplemente no entiendo dónde se agregó porque en mi directorio de inicio known_hosts - el archivo no se vio afectado cuando
eliminé la

157

Para aquellos de ustedes que están configurando MSYS Git en Windows usando PuTTY a través del símbolo del sistema estándar, la forma de agregar un host al caché de PuTTY es ejecutar

> plink.exe <host>

Por ejemplo:

> 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)

Solo responde yy luego Ctrl + C el resto.

Sin embargo, compruebe la huella digital. Esta advertencia está ahí por una buena razón. Huellas digitales para algunos servicios de git (edite para agregar más):


15
Esta debería ser la respuesta aceptada. Es precisamente a lo que se refiere el mensaje de error. En mi caso, cuando cloné, había usado un FQDN, pero en mi nueva máquina solo había iniciado sesión con el nombre de dominio local corto. Tuve que iniciar sesión a través de putty o plink como FQDN para almacenar en caché la clave para el nombre de host en el origen. Puede ser útil verificar el nombre de host que se usa como remoto usando "git remote -v".
peabody

3
También funciona para usar PuTTY interactivo para el host que está tratando de usar. Por ejemplo, si está intentando clonar un repositorio de Github por primera vez en una máquina Windows nueva, use PuTTY para abrir una sesión en el host 'github.com', acepte el mensaje sobre la confianza del servidor y luego clone en el la línea de comando debería funcionar.
Jeremy McGee

1
Puede decir que MSYS git está intentando usarlo plinkejecutando $ set | grep GIT_SSHy comprobandoGIT_SSH='C:\Program Files (x86)\PuTTY\plink.exe'
shuckc

2
Terminé resolviendo esto agregando mi clave a Pageant y accediendo al host con Putty directamente. Esto le pide que agregue el host a la caché. Haciendo lo mismo.
Knossos

1
Si su repositorio git se sirve en un puerto SSH personalizado, utilice -Ppara seleccionar el puerto, tales como: plink.exe example.com -P 2222. Pude clonar desde github pero no desde mi servidor personal, y esto me confundió muchísimo.
Hay

79

Intente hacer un "set | grep -i ssh" desde el indicador de Git Bash

Si su configuración es como la mía, probablemente tenga estos configurados:

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

hice un

unset GIT_SSH
unset PLINK_PROTOCOL
unset GIT_SVN

y funcionó después de eso, ... supongo que Putty guarda sus claves en otro lugar como $ HOME / .ssh o algo ... (También tuve un problema en una caja donde $ HOME estaba configurado en "C: \ Users \ usrnam "en lugar de" / C / Users / usrnam / "

de todos modos, su kilometraje puede variar, pero eso me solucionó. :-)

(probablemente solo hacer el GIT_SSH sin configurar es suficiente, pero estaba en una buena racha)

Nota: si desarmar no funciona para usted, intente esto:

set GIT_SSH=

1
"unset GIT_SSH" funcionó para mí. Había configurado Pageant / putty anteriormente para un servidor diferente, pero cuando construí nuevas claves usando el indicador de Git Bash, necesitaba regresar. Gracias por la ayuda.
Supermitch

después de seguir tus pasos llegué más lejos, pero ahora aparece un error de "mac corrompido en la entrada" ... ¿alguna vez has visto ese?
CD Smith

2
Al instalar git, puede optar por NO establecer esas variables. Incluso es la variante predeterminada. Aunque también elegí la integración plink, por eso estoy aquí) Gracias.
Antony Hatchkins

1
Esto también funcionó para mí en Win7. Aparentemente, la configuración de git bash con plink estaba causando el problema en mi caso.
nhylated

2
unset GIT_SSHtambién funcionó para mí, aunque tengo que hacerlo cada vez que lanzo git bash, lo cual es bastante aburrido. ¿Alguna idea de cómo automatizar eso?
Loïc

19

Sospecho que su GIT_SSHvariable de entorno está configurada en %ProgramFiles(x86)%\putty\plink.exe. Por alguna razón, PLink no usa el .ssh/known_hostsarchivo en su directorio de usuario para almacenar las claves de hosts remotos.

Si este es realmente su caso, y podría serlo a propósito si desea usar el concurso, primero debe usar PLink para conectarse al anfitrión.

"$GIT_SSH" user@hostname

Deberías recibir un mensaje similar

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)

Una vez que haya respondido ya la pregunta y se haya conectado correctamente al host remoto, debe estar listo. Adelante, intente empujar de nuevo.


Esto fue todo para mí usando Git Bash en Windows con PLink / Pageant. ¡Muchas gracias!
amsross

1
Usando un repositorio Stash (ahora Bitbucket), tuve que usar"$GIT_SSH" -P 7999 git@stash.domain.local
Julien

4

No basta con enviar un mensaje al host, al menos en Windows. Eso agrega la clave de host a, ssh/known_hostspero el error aún persiste.

Debes cerrar la ventana de git bash y abrir una nueva. Luego, se borra la caché del registro y luego funciona el push / pull.


ssh/known_hosts¿Es relativo a qué?% PERFIL DE USUARIO% Tengo este problema en Win 7 y no hay solución ...
Frank Nocke

2

Rene, tu HOMEvariable no está configurada correctamente. Cambie a c:\Users\(your-username)o simplemente a %USERNAME%.


2

Solución con Plink

Guarde este script de Python en 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

Probado en Win7x64 y Python 2.7 .

Entonces corre:

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

Y elige importar al registro. El keyscan recuperará la clave pública para el dominio (tuve mis problemas con bitbucket), y luego el script de Python lo convertirá al formato Plink.


2

Tuve el mismo problema y se olvidó de conectarse a SSH en el puerto donde está el repositorio actual , no solo el puerto SSH general, ¡entonces la clave de host es diferente!


También use exactamente la misma forma de especificar el host, por ejemplo, no gitserver.example.com para ssh y gitserver para git.
Matthijs P

2

Simplemente abra Putty e intente establecer una conexión con el servidor remoto al que desea enviar su código. cuando aparezca el cuadro de diálogo, presione Sí (confía en el control remoto), entonces todo estará bien.


2

Ambiente de trabajo:

  • Windows 10
  • git
  • masilla

Primero: Elimine putty known_hosts en registy de acuerdo con Regedit.
Entonces: Ejecutar el comando %GIT_SSH% user@hostnameen el cmd de Windows resuelve el problema.

Espero que os ayude a todos.


1

Yo también tuve el mismo problema cuando intentaba clonar un repositorio en mi máquina con Windows 7. Probé la mayoría de las respuestas mencionadas aquí. Ninguno de ellos funcionó para mí.

Lo que funcionó para mí fue ejecutar el programa Pageant (agente de autenticación Putty). Una vez que el concurso se ejecutó en segundo plano, pude clonar, empujar y extraer desde / hacia el repositorio. Esto funcionó para mí, puede deberse a que configuré mi clave pública de manera que cada vez que se usa por primera vez se requiere una contraseña y se inicia el concurso.


Recibe otro mensaje de error cuando se trata de un problema de concurso. No Connection abandoned, pero algo asíAccess denied (private key)
Andrey Regentov

1

Cambiar de PuTTY a OpenSSH solucionó este problema, sin necesidad de desarmar GIT_SSH, etc.


Si recibe el mensaje sobre la clave de host no reconocida mientras realiza las operaciones git push / pull utilizando ATLASSIAN SOURCETREE, no tiene la capacidad de responder y / ny la operación push / pull se cancelará sin almacenar la clave en caché. Sin embargo, ir a SourceTree Tools-> Options (pestaña General) y cambiar el SSH Client en (en SSH Client Configuration) de PuTTY a OpenSSH permitirá que la clave se almacene en caché sin cambiar nada más.
Rod Dewell

1

Resolví un problema similar usando esta solución .

Solo tiene que cambiar a Embedded Git, presionar, presionar el botón Sí y luego volver a System Git.

Puedes encontrar esta opción en

Tools -> Options -> Git

1
Ahora en la ubicación v2.5.5.0:C:\Users\{UserName}\AppData\Local\SourceTree\app-2.5.5\tools\putty> .\plink.exe {YourNewHost}
John_J

1

Como respondió Roman Starkov , plinknecesita agregar el host a su caché.

Para las personas que usan extensiones de Git :

  1. Abrir extensiones de Git
  2. Vaya a Herramientas -> Configuración -> SSH
  3. Copie la ruta a "plink.exe" (si usa PuTTY) / "klink.exe" (si usa KiTTY)
  4. En una consola, ejecute el siguiente comando:

(reemplazar con las rutas reales)

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

p.ej

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

Nota : ¡Asegúrese de utilizar el mismo plink / klink que utiliza Git Extensions!


0

Agregar el host directamente con Bash no resolvió el problema, el error aún se producía al usar 'Obtener todo' en Extensiones de Git. Al usar 'Pull' en una rama, Git Extensions agregó automáticamente el host requerido con una pantalla emergente Bash. Después de hacer esto, pude usar 'Obtener todo' nuevamente. No estoy seguro de qué hace Git Extensions de manera diferente.


0

Probé todos los métodos anteriores, pero ninguno de ellos pudo solucionar el mismo problema en mi computadora portátil. Finalmente, en lugar de empujar la rama al origen en git bash, trunco ​​para usar la opción de empujar de TortoiseGit para empujar, luego aparece una ventana para pedirme que agregue la nueva clave de host a la caché, después de hacer clic en el botón sí, todo va bien ahora.

Espero que os ayude a todos.


0

Cambié un disco duro, instalé Windows. Cuando intentó cargar archivos, recibió esta ventana de comando.

Presioné "y", luego Ctrl + C. Abrí putty.exe, agregué una tecla anterior, regresé a git y presioné archivos.


0

Simplemente desinstale las extensiones de Git e instale nuevamente eligiendo OpenSSH en lugar de


0

En Windows 7 o 10, el truco que me funcionó es eliminar la variable de sistema GIT_SSH. Antes estaba configurado para usar Plink y ahora fue reemplazado por Putty. Esto estaba causando el error Plink.exe

También hubo una instalación antigua de Git (versión de 32 bits) y una actualización a Git (por ejemplo, Git-2.20.1-64-bit.exe) ya que la PC tenía un sistema operativo de 64 bits.

De todos modos, Git ni siquiera usó Putty / Plink, ya que en la instalación de Git estaba predeterminado usar Open SSH.


0

Si recibe el mensaje sobre la clave de host no reconocida mientras realiza las operaciones git push / pull utilizando ATLASSIAN SOURCETREE, no tiene la capacidad de responder y / ny la operación push / pull se cancelará sin almacenar la clave en caché. Sin embargo, ir a SourceTree Tools-> Options (pestaña General) y cambiar el SSH Client en (en SSH Client Configuration) de PuTTY a OpenSSH permitirá que la clave se almacene en caché sin cambiar nada más.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.