Come impedire che la password per decrittografare la chiave privata debba essere inserita ogni volta che si utilizza Git Bash su Windows?

Ho un servizio di costruzione automatica che scarica da un repository privato git. Il problema è che quando tenta di clonare un repository deve fornire la password, perché non viene ricordata; quindi poiché non esiste alcuna interazione umana, attende per sempre la password. Come posso forzarlo a ricordare da id_rsa.pub?

Per gli utenti Windows, basta notare che è così che ho impostato l'ambiente Git Bash per accedere una volta all'avvio. Modifico il mio ~/.bashrcfile:

eval `ssh-agent`
ssh-add

Quindi quando avvio Git Bash, sembra:

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 ora posso ssh su altri server senza accedere ogni volta.

Questa risposta spiega come salvare il nome utente e la password di GitHub in modo permanente, non la passphrase della chiave SSH.

In Windows, esegui

$ git config --global credential.helper wincred

Ciò significa che la prossima volta che spingi, inserirai il tuo nome utente e password come al solito, ma verranno salvati nelle credenziali di Windows. Dopo non dovrai più inserirli.

Come in, Push to GitHub senza inserire username e password ogni volta (Git Bash su Windows) .

Preferisco non dover digitare la mia passphrase SSH all'apertura di nuovi terminali; sfortunatamente la soluzione di starmonkey richiede che la password sia digitata per ogni sessione. Invece, ho questo nel mio .bash_profilefile:

# 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

Questo ricorderà la mia passphrase anche per le nuove sessioni terminali; Devo inserirlo solo una volta quando apro il mio primo terminale dopo l'avvio.

Vorrei accreditare dove ho preso questo; è una modifica del lavoro di qualcun altro, ma non ricordo da dove provenga. Grazie autore anonimo!

Aggiornamento 2019-07-01: non penso che tutto ciò sia necessario. Ora lavoro costantemente assicurandomi che il mio .bash_profilefile esegua ssh-agent:

eval $(ssh-agent)

Quindi ho impostato un sshfile di configurazione come questo:

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

Se capisco correttamente la domanda, stai già utilizzando una chiave SSH autorizzata nel servizio di compilazione, ma vuoi evitare di dover digitare la passphrase per ogni clone?

Posso pensare a due modi per farlo:

1. Se il servizio di compilazione viene avviato in modo interattivo: prima di avviare il servizio di compilazione, iniziare ssh-agentcon un timeout sufficientemente lungo ( -topzione). Quindi utilizzare ssh-add(msysGit dovrebbe avere quelle) per aggiungere tutte le chiavi private necessarie prima di iniziare il servizio di compilazione. Dovresti comunque digitare tutte le passphrase, ma solo una volta per avvio del servizio.

2. Se vuoi evitare di dover digitare le passphrase, puoi sempre rimuovere le passphrase dalle chiavi SSH, come descritto in /server/50775/how-do-i-change-my- passphrase chiave-privata , impostando una nuova passphrase vuota. Questo dovrebbe eliminare completamente la richiesta della password, ma è persino meno sicura dell'opzione precedente.

Quando ho provato a spingere il mio codice, ho ricevuto l'errore di seguito:

$ 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

Dopo alcune ore di ricerca, ho scoperto che devo usare il comando seguente:

$ git config --global credential.helper cache

Dopo aver eseguito il comando sopra, ho ricevuto la richiesta di inserire il mio nome utente e la mia password GitHub. Dopo aver fornito le credenziali corrette, sono in grado di inviare il mio codice.

La soluzione giusta è:

1. Esegui il terminale predefinito di Windows - cmd e ottieni la directory del tuo profilo principale

   echo %USERPROFILE%
   

2. Esegui Git Bash nella directory sopra e crea il .bashrcfile con il comando

   echo "" > .bashrc
   

3. Apri il .bashrcfile con il tuo editor di testo preferito e incolla il codice dalla Guida di GitHub in quel file:

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

4. Riavvia Git Bash e ti chiede la password (solo la prima volta) e il gioco è fatto. Nessuna password che disturba di nuovo.

È necessario creare il authorized_keysfile nella .sshcartella dell'utente in cui si intende connettersi al server del repository. Ad esempio, supponendo che tu usi il nome utente buildservicesu repo.serverpuoi eseguire:

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

Quindi devi controllare le seguenti cose:

1. Quella id_rsachiave privata corrispondente è presentata in builservice@build.server:~/.shh/id_rsa.

2. Quell'impronta digitale di repo.server è memorizzata nel buildservice@build.server:~/.ssh/known_hostsfile. In genere ciò avverrà dopo il primo tentativo di sshconnessione a repo.server.