Como impedir que a senha para descriptografar a chave privada seja inserida sempre que você usar o Git Bash no Windows?

Eu tenho um serviço de construção automática que faz o download de um repositório privado git. O problema é que, ao tentar clonar o repositório, é necessário fornecer a senha, porque não é lembrada; então, como não há interação humana, ele espera para sempre a senha. Como forçar a lembrança de id_rsa.pub?

Para usuários do Windows, basta observar que é assim que eu configuro o ambiente do Git Bash para efetuar login uma vez ao iniciá-lo. Eu edito meu ~/.bashrcarquivo:

eval `ssh-agent`
ssh-add

Então, quando eu inicio o Git Bash, ele se parece com:

Welcome to Git (version 1.7.8-preview20111206)
(etc)
Agent pid 3376
Enter passphrase for /c/Users/starmonkey/.ssh/id_dsa:
Identity added: /c/Users/starmonkey/.ssh/id_dsa (/c/Users/starmonkey/.ssh/id_dsa)

E agora eu posso ssh para outros servidores sem fazer login sempre.

Esta resposta explica como obter o nome de usuário e a senha do GitHub para serem armazenados permanentemente, não a senha da chave SSH.

No Windows, basta executar

$ git config --global credential.helper wincred

Isso significa que na próxima vez em que você enviar, digite seu nome de usuário e senha como de costume, mas eles serão salvos nas credenciais do Windows. Você não precisará digitá-los novamente depois disso.

Por exemplo, envie para o GitHub sem inserir nome de usuário e senha todas as vezes (Git Bash no Windows) .

Prefiro não precisar digitar minha senha SSH ao abrir novos terminais; infelizmente, a solução da starmonkey exige que a senha seja digitada em todas as sessões. Em vez disso, tenho isso no meu .bash_profilearquivo:

# Note: ~/.ssh/environment should not be used, as it
#       already has a different purpose in SSH.

env=~/.ssh/agent.env

# Note: Don't bother checking SSH_AGENT_PID. It's not used
#       by SSH itself, and it might even be incorrect
#       (for example, when using agent-forwarding over SSH).

agent_is_running() {
    if [ "$SSH_AUTH_SOCK" ]; then
        # ssh-add returns:
        #   0 = agent running, has keys
        #   1 = agent running, no keys
        #   2 = agent not running
        ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]
    else
        false
    fi
}

agent_has_keys() {
    ssh-add -l >/dev/null 2>&1
}

agent_load_env() {
    . "$env" >/dev/null
}

agent_start() {
    (umask 077; ssh-agent >"$env")
    . "$env" >/dev/null
}

if ! agent_is_running; then
    agent_load_env
fi

# If your keys are not stored in ~/.ssh/id_rsa or ~/.ssh/id_dsa, you'll need
# to paste the proper path after ssh-add
if ! agent_is_running; then
    agent_start
    ssh-add
elif ! agent_has_keys; then
    ssh-add
fi

unset env

Isso também lembrará minha senha para novas sessões de terminal; Eu só tenho que digitá-lo uma vez quando abro meu primeiro terminal após a inicialização.

Eu gostaria de creditar onde consegui isso; é uma modificação do trabalho de outra pessoa, mas não me lembro de onde veio. Obrigado autor anônimo!

Atualização 2019-07-01: Não acho que tudo isso seja necessário. Agora, eu sempre tenho esse trabalho assegurando que meu .bash_profilearquivo execute o ssh-agent:

eval $(ssh-agent)

Então eu montei um ssh arquivo de configuração como este:

touch ~/.ssh/config
chmod 600 ~/.ssh/config
echo 'AddKeysToAgent yes' >> ~/.ssh/config

Se entendi a pergunta corretamente, você já está usando uma chave SSH autorizada no serviço de compilação, mas deseja evitar a digitação da senha para cada clone?

Eu posso pensar em duas maneiras de fazer isso:

1. Se o serviço de construção estiver sendo iniciado interativamente: Antes de iniciar o serviço de construção, inicie ssh-agentcom um tempo limite suficientemente longo ( -topção). Em seguida, use ssh-add(o msysGit deve ter esses) para adicionar todas as chaves privadas necessárias antes de iniciar o serviço de compilação. Você ainda precisará digitar todas as senhas, mas apenas uma vez por lançamento do serviço.

2. Se você quiser evitar digitar as frases secretas, sempre poderá removê-las das chaves SSH, conforme descrito em /server/50775/how-do-i-change-my- senha de chave privada , configurando uma nova senha vazia. Isso deve eliminar completamente o prompt de senha, mas é ainda menos seguro que a opção anterior.

Quando tentei enviar por push meu código, recebi o erro abaixo:

$ git push origin dev

remote: Too many invalid password attempts. Try logging in through the website with your password.
fatal: unable to access 'https://naushadqamar-1@bitbucket.org/xxxx/xxxx-api.git/': The requested URL returned error: 403

Após algumas horas de pesquisa, descobri que precisava usar o comando abaixo:

$ git config --global credential.helper cache

Depois de executar o comando acima, recebi o prompt para inserir meu nome de usuário e senha do GitHub. Depois de fornecer as credenciais corretas, sou capaz de enviar meu código por push.

A solução certa é:

1. Execute o terminal padrão do Windows - cmd e obtenha o diretório do seu perfil principal

   echo %USERPROFILE%
   

2. Execute o Git Bash no diretório acima e crie o .bashrcarquivo com o comando

   echo "" > .bashrc
   

3. Abra o .bashrcarquivo com seu editor de texto favorito e cole o código da Ajuda do GitHub nesse arquivo:

   env=~/.ssh/agent.env
   ...
   COPY WHOLE CODE FROM URL - I can't add it to Stack Overflow because it breaks layout... OMG!
   

4. Reinicie o Git Bash e ele solicita sua senha (somente na primeira vez) e pronto. Nenhuma senha incomodando novamente.

Você precisa criar o authorized_keysarquivo na .sshpasta do usuário sob a qual você irá se conectar ao servidor de repositório. Por exemplo, supondo que você use o nome buildservicede usuário, repo.servervocê pode executar:

cd ~buidservice
mkdir ./ssh
cat id_rsa.pub >> .ssh/authorized_keys

Então você deve verificar o seguinte:

1. Essa id_rsachave privada correspondente é apresentada em builservice@build.server:~/.shh/id_rsa.

2. Essa impressão digital do repo.server é armazenada no buildservice@build.server:~/.ssh/known_hostsarquivo. Normalmente, isso será feito após a primeira tentativa de sshconexão com o repo.server.