I have cloned my git repository over ssh. So, each time I communicate with the origin master by pushing or pulling, I have to reenter my password. How can I configure git so that I do not need to enter my password multiple times?
-
7Seems like a security issue, you don't have to use any passwords to do normal commits, but a push is the type of thing you'd want to re-authenticate with, but perhaps I'm old fashioned. – Alex Sexton Oct 20 '09 at 16:31
-
Other possibly related Questions: [Git keeps prompting me for a password](https://stackoverflow.com/questions/7773181/git-keeps-prompting-me-for-a-password) and [Git keeps prompting me for a password](https://stackoverflow.com/q/7773181/4575793) Cross site: [git with ssh keeps asking for passphrase everytime (*on U&L*)](https://unix.stackexchange.com/q/594529/318461) – Cadoiz Sep 13 '22 at 15:07
14 Answers
Had a similar problem with the GitHub because I was using HTTPS protocol. To check what protocol you're using just run
git config -l
and look at the line starting with remote.origin.url
. To switch your protocol
git config remote.origin.url git@github.com:your_username/your_project.git

- 29,542
- 12
- 100
- 122

- 3,388
- 2
- 13
- 3
-
16this doesn't work when repo is private and you are not the owner. I just faced with an `Permission denied` error. – ogzd Feb 11 '13 at 15:47
-
10
-
2@ogzd GitHub (or whatever service you're using) needs your public SSH key before this will work, but this is still the correct solution. – MattM Apr 28 '17 at 16:49
-
2an alternative is `git remote set-url origin git@github.com:your_username/your_project.git` – icosamuel Apr 23 '19 at 14:31
-
Now it just changed from `Password for 'https://example@bitbucket.org':` to `Enter passphrase for key '/home/example/.ssh/id_rsa':` – Black Jan 31 '20 at 08:20
Try ssh-add
, you need ssh-agent
to be running and holding your private key
(Ok, responding to the updated question, you first run ssh-keygen
to generate a public and private key as Jefromi explained. You put the public key on the server. You should use a passphrase, if you don't you have the equivalent of a plain-text password in your private key. But when you do, then you need as a practical matter ssh-agent
as explained below.)
You want to be running ssh-agent
in the background as you log in. Once you log in, the idea is to run ssh-add
once and only once, in order to give the agent your passphrase, to decode your key. The agent then just sits in memory with your key unlocked and loaded, ready to use every time you ssh somewhere.
All ssh-family commands1 will then consult the agent and automatically be able to use your private key.
On OSX (err, macOS), GNOME and KDE systems, ssh-agent
is usually launched automatically for you. I will go through the details in case, like me, you also have a Cygwin or other windows environment where this most certainly is not done for you.
Start here: man ssh-agent
.
There are various ways to automatically run the agent. As the man page explains, you can run it so that it is a parent of all your login session's other processes. That way, the environment variables it provides will automatically be in all your shells. When you (later) invoke ssh-add
or ssh
both will have access to the agent because they all have the environment variables with magic socket pathnames or whatever.
Alternatively, you can run the agent as an ordinary child, save the environment settings in a file, and source that file in every shell when it starts.
My OSX and Ubuntu systems automatically do the agent launch setup, so all I have to do is run ssh-add
once. Try running ssh-add
and see if it works, if so, then you just need to do that once per reboot.
My Cygwin system needed it done manually, so I did this in my .profile
and I have .bashrc
source .profile
:
. .agent > /dev/null
ps -p $SSH_AGENT_PID | grep ssh-agent > /dev/null || {
ssh-agent > .agent
. .agent > /dev/null
}
The .agent
file is created automatically by the script; it contains the environment variables definitions and exports. The above tries to source the .agent file, and then tries to ps(1)
the agent. If it doesn't work it starts an agent and creates a new agent file. You can also just run ssh-add
and if it fails start an agent.
1. And even local and remote
sudo
with the right pam extension.
- 1
- 1

- 143,651
- 25
- 248
- 329
-
2Rather than sourcing the output from `ssh-agent` it's probably neater to use: ```eval `ssh-agent` ``` – scottsome Feb 18 '16 at 09:08
If you have cloned using HTTPS (recommended) then:-
git config --global credential.helper cache
and then
git config --global credential.helper 'cache --timeout=2592000'
timeout=2592000 (30 Days in seconds) to enable caching for 30 days (or whatever suits you).
Now run a simple git command that requires your username and password.
Enter your credentials once and now caching is enabled for 30 Days.
Try again with any git command and now you don't need any credentials.
For more info:- Caching your GitHub password in Git
Note : You need Git 1.7.10 or newer to use the credential helper. On system restart, we might have to enter the password again.
Update #1:
If you are receiving this error git: 'credential-cache' is not a git command. See 'get --help'
then replace git config --global credential.helper 'cache --timeout=2592000'
with git config --global credential.helper 'store --file ~/.my-credentials'
Update #2:
If you keep getting the prompt of username and password and getting this issue:
Logon failed, use ctrl+c to cancel basic credential prompt.
Reinstalling the latest version of git worked for me.
Update #3:
Password authentication is temporarily disabled as part of a brownout. Please use a personal access token instead.
- Generate Github accessToken
- Unset existing credential cache
git config --global --unset credential.helper
git config --global credential.helper 'store --file ~/.my-credentials'
- Any git command that'll prompt for
username
&password
and enter token instead of password.

- 1,540
- 17
- 28
-
-
@joedotnot for all OS. You can also browse the mentioned link and there you will find OS option just below the heading. – Nishant Thapliyal Dec 25 '18 at 14:39
-
-
@Charles Hi, I've just tested the same and it is working as expected. – Nishant Thapliyal May 18 '20 at 06:14
-
This is about configuring ssh, not git. If you haven't already, you should use ssh-keygen
(with a blank passphrase) to create a key pair. Then, you copy the public key to the remote destination with ssh-copy-id
. Unless you have need of multiple keys (e.g. a more secure one with a passphrase for other purposes) or you have some really weird multiple-identity stuff going on, it's this simple:
ssh-keygen # enter a few times to accept defaults
ssh-copy-id -i ~/.ssh/id_rsa user@host
Edit:
You should really just read DigitalRoss's answer, but: if you use keys with passphrases, you'll need to use ssh-add <key-file>
to add them to ssh-agent
(and obviously start up an ssh-agent
if your distribution doesn't already have one running for you).

- 479,068
- 72
- 370
- 318
-
2I'm not sure this answers the question, he must have already done that or he would not be able to reach the site. The answer he needs is: `ssh-agent`, as he wants to bypass the enter-the-passphrase-every-time problem. Not downvoting but I think you need to improve this answer, unless I'm the one that misunderstood... – DigitalRoss Oct 20 '09 at 16:32
-
2@DigitalRoss: Ah, I wasn't sure from reading the question if the OP actually had the keys set up. You're probably right though, and I was deliberately trying to suggest not using a passphrase. However, you're of course right about `ssh-agent`. +1 to you! – Cascabel Oct 20 '09 at 16:34
-
I am confused whether I need to use ssh-keygen or ssh-add. In my ~/.ssh/ directory I only have two files: config and known_hosts. It seems that ssh-add requires another file ~/.ssh/id_rsa. Should I create that file first using ssh-keygen as @Jefromi explained? – reprogrammer Oct 20 '09 at 17:22
-
Yes, you need to create the key before you can copy it to the remote server. I think perhaps we were confused by your use of the word "passphrase" - that's what `ssh-*` calls the passphrase needed to make use of the key - where you really meant your actual user password on the remote? – Cascabel Oct 20 '09 at 17:27
-
-
You should be okay now then, right? Use ssh-keygen and ssh-copy-id as I described above. Or give a passphrase if you're really worried about security, and use ssh-agent, looking at DigitalRoss' answer. – Cascabel Oct 20 '09 at 18:00
-
Yes, you should have said password, which is an authentication method, rather than passphrase, which meant that you had an encrypted private key. In the former case it's the server asking, in the later case it's your clientt. It's considered unprofessional to use a null passphrase private key, if you do, it's like leaving a password around that works on every instance out there of your public key. – DigitalRoss Oct 20 '09 at 18:28
Make sure that when you cloned the repository, you did so with the SSH URL and not the HTTPS; in the clone URL box of the repo, choose the SSH protocol before copying the URL. See image below:

- 23,770
- 8
- 136
- 129
-
1This is immensely helpful! I feel it is a common theme to make an example project, start working on it and after some time deciding to put it in a git repo. I wanted to do it without SSH, but after I got sick of typing my credentials decided to switch to SSH. My repo was cloned with standard url so it didn't work as expected. You saved me a lot of time! – GeorgiG Dec 31 '20 at 13:04
Extending Muein's thoughts for those who prefer to edit files directly over running commands in git-bash or terminal.
Go to the .git directory of your project (project root on your local machine) and open the 'config' file. Then look for [remote "origin"] and set the url config as follows:
[remote "origin"]
#the address part will be different depending upon the service you're using github, bitbucket, unfuddle etc.
url = git@github.com:<username>/<projectname>.git

- 2,492
- 1
- 20
- 31
-
2This really helped. Secure and clean way to fix the issue. I think someone should improve Muein's answer with this one. – Luis Ortega Araneda Feb 16 '13 at 20:36
-
2
-
Getting this error "fatal: I don't handle protocol 'git@github.com:
/https'" – Shivam Bharadwaj Nov 14 '18 at 11:07 -
@ShivamBharadwaj a quick search revealed this thread https://stackoverflow.com/questions/30474447/git-fatal-i-dont-handle-protocol-http. Is there a possibility that you're copying the git clone command from some website and running into this issue? If yes, then try typing the complete command instead. – uchamp Nov 15 '18 at 07:26
I think there are two different things here. The first one is that normal SSH authentication requires the user to put the account's password (where the account password will be authenticated against different methods, depending on the sshd configuration).
You can avoid putting that password using certificates. With certificates you still have to put a password, but this time is the password of your private key (that's independent of the account's password).
To do this you can follow the instructions pointed out by steveth45:
If you want to avoid putting the certificate's password every time then you can use ssh-agent, as pointed out by DigitalRoss
The exact way you do this depends on Unix vs Windows, but essentially you need to run ssh-agent in the background when you log in, and then the first time you log in, run ssh-add to give the agent your passphrase. All ssh-family commands will then consult the agent and automatically pick up your passphrase.
Start here: man ssh-agent.
The only problem of ssh-agent is that, on *nix at least, you have to put the certificates password on every new shell. And then the certificate is "loaded" and you can use it to authenticate against an ssh server without putting any kind of password. But this is on that particular shell.
With keychain you can do the same thing as ssh-agent but "system-wide". Once you turn on your computer, you open a shell and put the password of the certificate. And then, every other shell will use that "loaded" certificate and your password will never be asked again until you restart your PC.
Gnome has a similar application, called Gnome Keyring that asks for your certificate's password the first time you use it and then it stores it securely so you won't be asked again.
-
-
there is one more way by writing `AddKeysToAgent yes` in .ssh/config. Then its loaded in the memory until you switch off the computer – infoclogged Aug 23 '17 at 20:55
ssh-keygen -t rsa
When asked for a passphrase ,leave it blank i.e, just press enter. as simple as that!!

- 35,413
- 11
- 95
- 121

- 345
- 3
- 3
-
4Be aware that if you do this, then anybody who has access to your development client has access to the repository server without needing a password. The ssh-agent/ssh-add combo gives much better security. – Peter V. Mørch Jul 31 '12 at 13:33
Try this from the box you are pushing from
ssh git@github.com
You should then get a welcome response from github and will be fine to then push.

- 1,296
- 13
- 16
-
2It is working for me ```Hi gkucmierz! You've successfully authenticated, but GitHub does not provide shell access.``` But somehow git still ask me for password when I try to push – gkucmierz Jun 16 '17 at 10:04
If you're using github, they have a very nice tutorial that explains it more clearly (at least to me).

- 1,615
- 4
- 17
- 42
I had to clone a git repo from a server that did not allow login vie ssh key but only with a user/password. I found no way to configure the Git Plugin to use a simple user/password combination so i added the the following shell command as pre-build step on a linux build machine which depends on the tool expect (apt-get install expect):
THIS IS NOT A GOOD WAY OF SOLVING THIS PROBLEM AS YOUR PASSWORD IS SHOWN AS CLEAR TEXT IN THE CONFIGURATION AND LOGS OF THE JENKINS JOB! ONLY USE IT IF THERE IS NO WAY TO CONFIGURE RSA-KEY AUTHENTIFICATION OR OTHER CONFIGURATION POSSIBILITES!
rm -rf $WORKSPACE &&
expect -c 'set timeout -1; spawn git clone USER@MYHOST:/MYPATH/MYREPO.git $WORKSPACE; expect "password:" {send "MYPASSWORD\r"}; expect eof'

- 1,359
- 1
- 13
- 18
I have being trying to avoid typing the passphrase all the time also because i am using ssh on windows. What i did was to modify my .profile file, so that i enter my passphrase one in a particular session. So this is the piece of code:
SSH_ENV="$HOME/.ssh/environment"
# start the ssh-agent
function start_agent {
echo "Initializing new SSH agent..."
# spawn ssh-agent
ssh-agent | sed 's/^echo/#echo/' > "$SSH_ENV"
echo succeeded
chmod 600 "$SSH_ENV"
. "$SSH_ENV" > /dev/null
ssh-add
}
# test for identities
function test_identities {
# test whether standard identities have been added to the agent already
ssh-add -l | grep "The agent has no identities" > /dev/null
if [ $? -eq 0 ]; then
ssh-add
# $SSH_AUTH_SOCK broken so we start a new proper agent
if [ $? -eq 2 ];then
start_agent
fi
fi
}
# check for running ssh-agent with proper $SSH_AGENT_PID
if [ -n "$SSH_AGENT_PID" ]; then
ps -fU$USER | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null
if [ $? -eq 0 ]; then
test_identities
fi
# if $SSH_AGENT_PID is not properly set, we might be able to load one from
# $SSH_ENV
else
if [ -f "$SSH_ENV" ]; then
. "$SSH_ENV" > /dev/null
fi
ps -fU$USER | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null
if [ $? -eq 0 ]; then
test_identities
else
start_agent
fi
fi
so with this i type my passphrase once in a session..

- 527
- 1
- 3
- 14
-
For windows using git for windows, I was able to get this to work by changing ps -fU$USER to ps -f -u $USERNAME. Hope that helps someone in the future. – Adam Marcionek Aug 05 '20 at 15:53
Add a single line AddKeysToAgent yes
on the top of the .ssh/config file. Ofcourse ssh-agent must be running beforehand. If its not running ( check by prep ssh-agent
) , then simply run it eval $(ssh-agent)
Now, the key is loaded systemwide into the memory and you dont have to type in the passphrase again.
The source of the solution is https://askubuntu.com/questions/362280/enter-ssh-passphrase-once/853578#853578

- 3,641
- 5
- 32
- 53
I tried all of these suggestions and more, just so I could git clone from my AWS instance. Nothing worked. I finally cheated out of desperation: I copied the contents of id_rsa.pub on my local machine and appended it to ~/.ssh/known_hosts on my AWS instance.

- 19
- 3