git - Chave de host do servidor não armazenada em cache


101

Tento enviar as alterações do meu repositório local para um repositório remoto. Quando eu digito:

git push origin

Estou tendo o erro a seguir:

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 posso resolver isso? Estou usando o git na linha de comando do Windows 7.

Editar

Quando tento fazer um ssh simples

ssh user@hostname

Estou tendo o erro a seguir:

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

De alguma forma, ele não criará o diretório, porque o caminho é inválido. Como consertar isto?

@eckes: Edit2

Minha casa está configurada como %HOMEDRIVE%%HOMEPATH%correto?


2
Parece que $HOMEnão está configurado corretamente. Tente definir a HOMEvariável de ambiente no Windows usando My Computer-> clique com o botão direito -> Properties-> Tab Advanced-> BotãoEnvironment Variables
eckes de

1
Não sou um cara do windows, mas me parece estranho que depois /c//(presumivelmente uma letra de unidade) você ainda tem %HOMEDRIVE%... Você pode economizar algum tempo mexendo com o valor e repetindo-o?
Cascabel

1
Expandir HOMEDRIVEe HOMEPATHe conjunto HOMEpara o valor resultante ...
Eckes

Respostas:


54

A mensagem significa que a chave do host de originnão está presente no arquivo de hosts confiáveis.

Para contornar isso, abra uma conexão SSH simples para origine o SSH perguntará se você deseja confiar no host remoto (do 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)?

Se você confiar no host remoto (ou seja, tipo yes), o SSH adicionará sua chave à lista de hosts conhecidos.

Depois disso, você deve ser capaz de fazer o seu git push origin.

Como alternativa, você também pode adicionar manualmente a chave de origina .ssh/known_hosts, mas isso requer que você aderir ao formato do known_hostsarquivo, conforme descrito na página do manual de sshd(Seção FORMATO DE ARQUIVO authorized_keys ).


4
Recebi a mesma mensagem ao fazer um push para o github, mas posso ssh para o github e tenho github.com em meu known_hostsarquivo.
Magnus Lindhe

1
Olhe para a resposta abaixo neste caso
Nikita Koksharov

3
Você pode usar PuTTY no Windows para os mesmos fins, no lugar de um cliente SSH de linha de comando.
brianmearns

1
Certifique-se de que os nomes de host sejam exatamente os mesmos. Por exemplo, se você instalou o git localmente e usa o nome 'home.mydomain.com' como remoto, mas armazena a chave usando putty para se conectar a 'localhost', isso não funcionará. Você precisa se conectar exatamente ao nome do host em seu url remoto.
Jason Goemaat

Para mim consertou tentando conectar com putty ao servidor. Vamos dizer que git url é ssh: //git@example.ex.com: 222 / something / shop.git, então eu entrei no campo Nome do host do putty example.ex.com e porta 222. Em seguida, a conexão falhou, mas acho que adicionou o dedo imprima onde for necessário. Só não entendo onde foi adicionado porque no meu diretório inicial known_hosts - o arquivo não foi afetado quando eu excluí a chave antiga
Darius.V

157

Para aqueles que estão configurando o MSYS Git no Windows usando PuTTY por meio do prompt de comando padrão, a maneira de adicionar um host ao cache do PuTTY é executar

> plink.exe <host>

Por exemplo:

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

Basta responder ye, em seguida, Ctrl + C o resto.

No entanto, verifique a impressão digital. Este aviso existe por um bom motivo. Impressões digitais para alguns serviços git (edite para adicionar mais):


15
Esta deve ser a resposta aceita. É exatamente a isso que a mensagem de erro se refere. No meu caso, quando fiz a clonagem, usei um FQDN, mas na minha nova máquina só fiz login usando o nome de domínio local abreviado. Tive que fazer o login via putty ou plink como FQDN para armazenar em cache a chave do nome do host na origem. Isso pode ajudar a cruzar a verificação do nome do host sendo usado como remoto usando "git remote -v".
peabody de

3
Também funciona para usar PuTTY interativo para o host que você está tentando usar. Por exemplo, se você estiver tentando clonar um repositório Github pela primeira vez em uma máquina Windows nova, use PuTTY para abrir uma sessão para o host 'github.com', aceite o prompt sobre a confiança do servidor e, em seguida, clone no linha de comando deve funcionar.
Jeremy McGee

1
Você pode saber que o MSYS git está tentando usar plinkexecutando $ set | grep GIT_SSHe verificandoGIT_SSH='C:\Program Files (x86)\PuTTY\plink.exe'
shuckc

2
Acabei resolvendo isso adicionando minha chave ao Pageant e acessando o host diretamente com Putty. Isso pede que você adicione o host ao cache. Fazendo a mesma coisa.
Knossos

1
Se seu repositório git é servido em uma porta SSH personalizado, use -Ppara selecionar a porta, tais como: plink.exe example.com -P 2222. Consegui clonar do github, mas não do meu servidor pessoal, e isso me confundiu profundamente.
Hay

79

Tente fazer um "set | grep -i ssh" no prompt do Git Bash

Se sua configuração for como a minha, você provavelmente tem estes conjuntos:

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

Eu fiz um

unset GIT_SSH
unset PLINK_PROTOCOL
unset GIT_SVN

e funcionou depois disso ... Acho que o putty salva suas chaves em outro lugar como $ HOME / .ssh ou algo assim ... (Também tive um problema em uma caixa em que $ HOME estava definido como "C: \ Usuários \ usrnam "em vez de" / C / Users / usrnam / "

de qualquer forma, sua milhagem pode variar, mas isso resolveu para mim. :-)

(provavelmente apenas fazer o GIT_SSH não definido é o suficiente, mas eu estava indo bem)

Observação: se não definir não funcionar para você, tente o seguinte:

set GIT_SSH=

1
"GIT_SSH não definido" funcionou para mim. Eu tinha configurado o Pageant / putty anteriormente para um servidor diferente, mas quando criei novas chaves usando o prompt do Git Bash, precisei voltar. Obrigado pela ajuda.
supermitch

depois de seguir seus passos eu fui mais longe, mas agora recebo um erro "mac interrompido na entrada" ... já viu esse?
CD Smith

2
Ao instalar o git, você pode optar por NÃO definir essas variáveis. É até a variante padrão. Embora eu tenha escolhido a integração com o plink também, é por isso que estou aqui) Obrigado.
Antony Hatchkins,

1
Isso funcionou para mim também no Win7. Aparentemente, a configuração do git bash com o plink estava causando o problema no meu caso.
nilado em

2
unset GIT_SSHfuncionou para mim também, embora eu tenha que fazer isso toda vez que lanço o git bash, o que é muito chato. Alguma ideia de como automatizar isso?
Loïc

19

Suspeito que sua GIT_SSHvariável de ambiente esteja definida como %ProgramFiles(x86)%\putty\plink.exe. Por alguma razão, o PLink não usa o .ssh/known_hostsarquivo em seu diretório de usuário para armazenar as chaves de hosts remotos.

Se este for realmente o seu caso, e pode ser propositalmente se você quiser usar o concurso, você precisa usar o PLink para se conectar ao host primeiro.

"$GIT_SSH" user@hostname

Você deve receber uma mensagem semelhante

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)

Depois de responder yà pergunta e se conectar com êxito ao host remoto, tudo estará pronto. Vá em frente e tente empurrar novamente.


Isso foi para mim usando Git Bash no windows com PLink / Pageant. Muito obrigado!
amsross de

1
Usando um repositório Stash (agora Bitbucket), tive que usar"$GIT_SSH" -P 7999 git@stash.domain.local
Julien

4

Apenas enviar um ssh para o host não é suficiente, pelo menos no Windows. Isso adiciona a chave do host, ssh/known_hostsmas o erro ainda persiste.

Você precisa fechar a janela do git bash e abrir uma nova. Então, o cache de registro é limpo e o push / pull funciona.


ssh/known_hostsestá relacionado a quê ?,% USERPROFILE% Estou tendo este problema no Win 7, e nenhuma solução ...
Frank Nocke

2

Rene, sua HOMEvariável não está configurada corretamente. Altere para c:\Users\(your-username)ou apenas para %USERNAME%.


2

Solução com Plink

Salve este script Python em 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

Testado em Win7x64 e Python 2.7 .

Então corra:

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

E escolha importar para o registro. O keyscan irá recuperar a chave pública para o domínio (eu tive meus problemas com o bitbucket), e então o script Python irá convertê-la para o formato Plink.


2

Tive o mesmo problema e esqueça de conectar - se ao SSH na porta onde está o repositório atual , não apenas a porta SSH geral, então a chave do host é diferente!


Use também exatamente a mesma maneira de especificar o host, por exemplo, não gitserver.example.com para ssh e gitserver para git.
Matthijs P

2

Basta abrir o Putty e tentar estabelecer conexão com o servidor remoto para o qual deseja enviar seu código. quando a caixa de diálogo for exibida, pressione Sim (você confia no controle remoto), então tudo ficará bem.


2

Ambiente de trabalho:

  • Windows 10
  • idiota
  • massa

Primeiro: Elimine o putty known_hosts no registo de acordo com o Regedit.
Então: Executar o comando %GIT_SSH% user@hostnameno cmd do Windows resolve o problema.

Espero que ajude todos vocês.


1

Eu também tive o mesmo problema quando estava tentando clonar um repositório em minha máquina com Windows 7. Tentei a maioria das respostas mencionadas aqui. Nenhum deles funcionou para mim.

O que funcionou para mim foi executar o programa Pageant (agente de autenticação Putty). Uma vez que o Pageant estava rodando em segundo plano, eu fui capaz de clonar, enviar e puxar de / para o repositório. Isso funcionou para mim, talvez porque eu configurei minha chave pública de forma que, sempre que for usada pela primeira vez, uma senha seja exigida e o Pageant seja iniciado.


Você recebe outra mensagem de erro quando é problema de concurso. Não Connection abandoned, mas algo comoAccess denied (private key)
Andrey Regentov,

1

Mudar de PuTTY para OpenSSH corrigiu esse problema para mim, sem a necessidade de remover GIT_SSH etc.


Se você receber a mensagem sobre a chave de host não reconhecida ao fazer operações git push / pull usando ATLASSIAN SOURCETREE, não terá a capacidade de responder s / n e a operação push / pull será cancelada sem armazenar a chave em cache. No entanto, ir para SourceTree Tools-> Options (General Tab) e alterar SSH Client em (em SSH Client Configuration) de PuTTY para OpenSSH permitirá que a chave seja armazenada em cache sem alterar nada mais.
Rod Dewell

1

Resolvi problema semelhante usando esta solução alternativa .

Você apenas tem que mudar para o Git Embedded, apertar, pressionar o botão Yes e então voltar para o System Git.

Você pode encontrar esta opção em

Tools -> Options -> Git

1
Agora na v2.5.5.0 local:C:\Users\{UserName}\AppData\Local\SourceTree\app-2.5.5\tools\putty> .\plink.exe {YourNewHost}
John_J

1

Conforme respondido por Roman Starkov , plinkprecisa adicionar o host ao cache.

Para pessoas que usam extensões Git :

  1. Abrir extensões Git
  2. Vá para Ferramentas -> Configurações -> SSH
  3. Copie o caminho para "plink.exe" (se estiver usando PuTTY) / "klink.exe" (se estiver usando KiTTY)
  4. Em um console, execute o seguinte comando:

(substitua pelos caminhos reais)

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

por exemplo

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

Nota : Certifique-se de usar o mesmo plink / klink que as extensões Git estão usando!


0

Adicionar o host diretamente com o Bash não resolveu o problema, o erro ainda ocorria ao usar 'Fetch all' nas extensões Git. Ao usar 'Pull' em um branch, o host necessário foi adicionado automaticamente pelas extensões Git com uma tela pop-up Bash. Depois de fazer isso, fui capaz de usar 'Fetch All' novamente. Não tenho certeza do que é feito pelas extensões Git de forma diferente.


0

Eu tentei todos os métodos acima, mas nenhum deles conseguiu resolver o mesmo problema no meu laptop. Finalmente, em vez de empurrar o branch para a origem no git bash, eu toco para usar a opção push do TortoiseGit para fazer o push, então uma janela aparece pedindo que eu adicione a nova chave de host ao cache, depois de clicar no botão sim, tudo vai bem agora.

Espero que ajude a todos vocês.


0

Mudei um disco rígido, instalei o Windows. Quando tentou fazer upload de arquivos recebeu esta janela de comando.

Pressionei "y", depois Ctrl + C. Abri putty.exe, adicionei uma tecla antiga que retornou ao git e empurrei os arquivos.


0

Basta desinstalar as extensões Git e instalar novamente escolhendo OpenSSH em vez de


0

No Windows 7 ou 10, o truque que funcionou para mim é excluir a variável de sistema GIT_SSH. Ele foi configurado antes para usar o Plink e agora foi substituído pelo Putty. Isso estava causando um erro no Plink.exe

Houve também uma instalação antiga do Git (versão de 32 bits) e atualização para o Git (por exemplo, Git-2.20.1-64-bit.exe), pois o PC era um sistema operacional de 64 bits.

De qualquer forma, o Putty / Plink nem era usado pelo Git já que na instalação do Git era padrão usar Open SSH.


0

Se você receber a mensagem sobre a chave de host não reconhecida ao fazer operações git push / pull usando ATLASSIAN SOURCETREE, você não terá a capacidade de responder s / n e a operação push / pull será cancelada sem armazenar a chave em cache. No entanto, ir para SourceTree Tools-> Options (General Tab) e alterar SSH Client em (em SSH Client Configuration) de PuTTY para OpenSSH permitirá que a chave seja armazenada em cache sem alterar nada mais.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.