93

I'm using git bash and I setup ssh key using ssh-keygen and each time I do something with a repo git ask me for passphrase for /c/Users/jankiewj/.ssh/id_rsa. Is there a way to disable that passphrase.

EDIT: I've edited original title (removed Windows) since I've just used fresh install of Ubuntu on my work laptop and when ssh key have pass phrase it always ask for it and the solution to fix this is the same. This probably work the same on MacOSX that is also Unix and use same basic tools.

3

6 Answers 6

123

You can run this in git bash, Windows WLS or bash on real GNU/Linux.

eval `ssh-agent -s`
ssh-add ~/.ssh/*_rsa

it will ask for pass phrase in the second command, and that's it. Each additional action you will need to do (which once required pass phrase) won't ask you for the pass phrase (see an example in the screen shot below):

adding pass phrase in git bash on Windows

12
  • 20
    I have to enter it again, as soon as I close git bash... is there a permanent solution?
    – Black
    Sep 18, 2018 at 7:59
  • 2
    @Black it's per bash session, I've put this in .bashrc so each time I open git bash I get the prompt and for that session I'm all set.
    – jcubic
    Sep 18, 2018 at 9:36
  • What exactly do you put in .bashrc? And where is .bashrc?
    – Black
    Sep 18, 2018 at 9:38
  • 1
    @Niing commands can do something that you don't know and print something else. You don't know what that command does. If you want to know for sure, you can read its source code, the program is open source.
    – jcubic
    Sep 16, 2021 at 6:25
  • 1
    @jcubic: it creates an new agent and prints the id of it :) Thanks I should check things like that.
    – Niing
    Sep 16, 2021 at 6:49
32

A slightly better and permanent solution is to auto launch the ssh-agent when opening the git bash on windows. You can copy/paste the below in your .profile or .bashrc. I prefer to put it on the .profile

env=~/.ssh/agent.env

agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }

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

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
    ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
    ssh-add
fi

unset env

This solution was taken from this github help article

8
  • I've put my simple code into .bashrc, how your solution different? On Windows bash each shell is independent so agent is never running when you run the shell.
    – jcubic
    Apr 5, 2019 at 7:41
  • 1
    Solution works fine by putting the code into the .bashrc. Prompting the ssh passphrase only at the first time. Safed my life. Thank you. Jun 10, 2019 at 19:39
  • 1
    This should really be the accepted answer as it presents a solution that is persistent and better meets what I think the OP was asking.
    – Richard D
    Jul 17, 2019 at 17:00
  • What do I do if I accidentally typed the wrong password on startup? Edit: Based on superuser.com/a/271673/647110, you can ssh-add -D to delete all keys. Aug 19, 2019 at 15:16
  • 3
    This solution still requires you to enter your passphrase when you first open git bash, and you have to have git bash open to run git commands. This is not a good permanent solution Jul 20, 2020 at 16:03
2

TDLR: For windows users,

  • run ssh-add "C:\\Users\\<your user>/.ssh/id_rsa"
  • not ssh-add ~/.ssh/id_rsa

For example I see this all the time:

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /c/Users/User/.ssh/id_rsa: 
Identity added: /c/Users/User/.ssh/id_rsa (/c/Users/User/.ssh/id_rsa)

$ git pull
Enter passphrase for key 'C:\Users\User/.ssh/id_rsa': 

Note the inconsistent path separators: the ssh-agent converts ~ using Unix path separators, but git uses Windows path separators instead. Given that the path of the id_rsa file is used as key, this explains why the cache is missed.

  • Another difference is C:/ instead of /c/
  • Related remark: When git asks you for the passphrase, it won't be cached, so you can be entering it there indefinitely. Try passing the phrase to ssh-add only.
  • On Windows, assume that ~ is "multivalued", so it's best to be explicit.
  • ssh-add looks at default locations like ~/.ssh/id_rsa. On Windows, assume that's ambiguous. Explicitly pass in the explicitly formatted path instead of relying on default paths:
    • ssh-add "C:\\Users\\<your user>/.ssh/id_rsa", i.e. in @velval's answer too.
4
  • NOTE That the question is about GIT Bash on Windows and also the accepted answer, so it's still ssh-add ~/.ssh/id_rsa (even on Windows). GIT Bash is a unix environment. The same will be in WSL (Windows Subsystem for Linux) so your answer is wrong.
    – jcubic
    Jun 7, 2021 at 19:22
  • If think that you didn't installed GIT Bash properly and installed git tools into cmd.exe, so this is not GIT Bash as in question. Please create another question where you can ask about cmd.exe instead of GIT Bash. This will only confuse people.
    – jcubic
    Jun 7, 2021 at 19:23
  • @jcubic My answer is about Git Bash on Windows too, just like the question and accepted answer. I'm pretty sure that is clear from my answer, but if not, where can I improve?
    – JBSnorro
    Jun 8, 2021 at 8:29
  • I know this is old, but putting in the full path instead of of ~/.ssh is what worked for me.
    – gin93r
    Jan 3 at 17:05
1

Im not sure if I want to recommend it, but when you create the Key and asked to set password, just hit enter and skip the password.

Have a look at this link for how to use ssh-keygen: https://help.github.com/articles/working-with-ssh-key-passphrases/

Perhaps ssh-agent can help you somehow. But not sure without knowing your current system.

6
  • 9
    definitely not a good answer Sep 9, 2019 at 2:40
  • 1
    It was the only way to solve it on windows 10. After following all the steps of "Generating a new SSH key and adding it to the ssh-agent" github guide, it was always asking me for the passphrase. Even after added it. That behavior was breaking my maven deployment flow because at mvn release:perform phase it tries to checkout the release tag without providing the passphrase. So only clearing the passphrase solved this issue. Dec 17, 2019 at 12:47
  • Not recommended. Then everybody accessing your machine can use the private/public key pair.
    – psuzzi
    Jun 4, 2022 at 9:15
  • yea.... if everyone who can access your machine can access your files, you have other issues to handle as well...... But still, what you say is correct.
    – David Bern
    Jun 4, 2022 at 18:44
  • 1
    This is the correct answer. Any valid solution to OP's question, namely not having to enter your passphrase, means effectively anyone with access to your computer can use your key without your passphrase. It's literally what was asked for and this is the simplest way to achieve that. If you want the extra protection from a passphrase, then you're going to have to keep entering that passphrase. What kind of passphrase is one you can use without entering it?
    – Kryomaani
    Sep 13, 2022 at 1:20
0

Keychain is a program to do this work intelligently.

It should be ran from the .bashrc (or equivalent) and it will setup the environment correctly no configuration other than which keys it should load.

This what I use: keychain --quiet key1.pem key2.pem

It realizes that the shell is Zsh and it worked exactly the same when I used Bash.

-2

Enter this git command in your repos location "ssh-keygen -p" This will then prompt you to enter the keyfile location, the old passphrase, and the new passphrase (which can be left blank to have no passphrase). Don't enter anything in new password and it will remove passphrase

3
  • 3
    Leaving a blank password is insecure and many corporate devs won't be able to have a blank passphrase due to restriction. It's a lame workaround, not a solution for OP issue.
    – cbaldan
    Jun 2, 2019 at 16:06
  • lame perhaps, but for local use only, Tasty and expeditious™
    – Jim P
    Sep 17, 2019 at 17:12
  • clearly not the best answer, but it is a valid answer. a security warning would be nice though.. Jan 11 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .