How to prevent that the password to decrypt the private key has to be entered every time when using Git Bash on Windows?

WindowsGitPasswordsSsh Keys

Windows Problem Overview


I've an automatic building service which download from a git private repository. The problem is that when it tries to clone repository it need to provide the password, because it is not remembered; so because there is no human interaction, it waits forever the password. How can I force it to remember from id_rsa.pub?

Windows Solutions


Solution 1 - Windows

For Windows users, just a note that this is how I set up the Git Bash environment to log me in once when I start it up. I edit my ~/.bashrc file:

eval `ssh-agent`
ssh-add

So when I start Git Bash, it looks like:

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)

And now I can ssh to other servers without logging in every time.

Solution 2 - Windows

This answer explains how to get the GitHub username and password to be stored permanently, not the SSH key passphrase.

In Windows, just run

$ git config --global credential.helper wincred

This means that the next time you push, you'll enter your username and password as usual, but they'll be saved in Windows credentials. You won't have to enter them again, after that.

As in, Push to GitHub without entering username and password every time (Git Bash on Windows).

Solution 3 - Windows

I prefer not to have to type my SSH passphrase when opening new terminals; unfortunately starmonkey's solution requires the password to be typed in for every session. Instead, I have this in my .bash_profile file:

# 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

This will remember my passphrase for new terminal sessions as well; I only have to type it in once when I open my first terminal after booting.

I'd like to credit where I got this; it's a modification of somebody else's work, but I can't remember where it came from. Thanks anonymous author!

Update 2019-07-01: I don't think all this is necessary. I now consistently have this working by ensuring my .bash_profile file runs the ssh-agent:

eval $(ssh-agent)

Then I set up an ssh configuration file like this:

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

Solution 4 - Windows

If I understand the question correctly, you're already using an authorized SSH key in the build service, but you want to avoid having to type the passphrase for every clone?

I can think of two ways of doing this:

  1. If your build service is being started interactively: Before you start the build service, start ssh-agent with a sufficiently long timeout (-t option). Then use ssh-add (msysGit should have those) to add all the private keys you need before you start your build service. You'd still have to type out all the passphrases, but only once per service launch.

  2. If you want to avoid having to type the passphrases out at all, you can always remove the passphrases from the SSH keys, as described in https://serverfault.com/questions/50775/how-do-i-change-my-private-key-passphrase, by setting an empty new passphrase. This should do away with the password prompt entirely, but it is even less secure than the previous option.

Solution 5 - Windows

When I tried to push my code, I got the below error:

$ git push origin dev

remote: Too many invalid password attempts. Try logging in through the website with your password.
fatal: unable to access 'https://[email protected]/xxxx/xxxx-api.git/': The requested URL returned error: 403

After a few hours of research, I found I need to use the below command:

$ git config --global credential.helper cache

After executing the above command, I got the prompt for entering my GitHub username and password. After providing the correct credentials, I am able to push my code.

Solution 6 - Windows

The right solution is:

  1. Run the Windows default terminal - cmd and get the directory of your master profile

     echo %USERPROFILE%
    
  2. Run Git Bash in the directory above and create the .bashrc file with the command

     echo "" > .bashrc
    
  3. Open the .bashrc file with your favourite text editor and paste code from GitHub Help into that file:

     env=~/.ssh/agent.env
     ...
     COPY WHOLE CODE FROM URL - I can't add it to Stack Overflow because it breaks layout... OMG!
    
  4. Restart Git Bash and it asks you for your password (only first time) and done. No password bothering again.

Solution 7 - Windows

You need to create the authorized_keys file under the .ssh folder of the user under which you are going to connect to the repository server. For example, assuming you use username buildservice on repo.server you can run:

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

Then you have to check the following things:

  1. That corresponding id_rsa private key is presented in [email protected]:~/.shh/id_rsa.

  2. That fingerprint of repo.server is stored in the [email protected]:~/.ssh/known_hosts file. Typically that will be done after the first attempt of ssh to connect to the repo.server.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionD.GiunchiView Question on Stackoverflow
Solution 1 - WindowsstarmonkeyView Answer on Stackoverflow
Solution 2 - WindowsStephen Tun AungView Answer on Stackoverflow
Solution 3 - WindowsConanView Answer on Stackoverflow
Solution 4 - WindowsmillimooseView Answer on Stackoverflow
Solution 5 - WindowsNaushad QamarView Answer on Stackoverflow
Solution 6 - WindowsManic DepressionView Answer on Stackoverflow
Solution 7 - WindowsbeduinView Answer on Stackoverflow