I installed my SSH private key in ~/.ssh/id_rsa and set its permissions to 0600. When I connect to an SSH server which uses my private key in Terminal.app via ssh, a dialog pops up and asks me to enter my password to access the id_rsa file:

enter image description here

I see the same dialog when I connect to an FTP server with the Interarchy GUI client.

Update: I see this dialog every time I connect regardless of whether I check "Remember password in my keychain". It appears two more times if the OK button is clicked regardless of what is entered in the password field.

When I relax these permissions to, say, 0640, I no longer see a dialog asking me for my password but ssh aborts with the following error:

Permissions 0640 for '/Users/myusername/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/myusername/.ssh/id_rsa

I find the password dialog extremely annoying and I am sure there must be some way to avoid having to dismiss this dialog SSH needs to access the id_rsa file.

Note: I am running Mac OS X 10.6.8.

19 Answers 19


Make sure you have a corresponding id_rsa.pub or id_dsa.pub in your ~/.ssh directory.

When I had an id_rsa but not a corresponding id_rsa.pub, Mac OS X kept popping up the dialog and remember passowrd in my keychain did nothing.

cd ~/.ssh
ssh-keygen -y -f id_rsa > id_rsa.pub

generated the appropriate public key file for me.

If you already had your public file there (rename it to another name) and generate the public key again using the above command, you'll notice that the generated and the old one are not equal. Somehow the older versions of Mac OS X generated a public key that Lion does not like anymore, generating it again fixes that.

For the curious, the key is exactly the same, the part that changes is that there is no "comments" section after the key on the file any longer.

  • 2
    This solution might not make a lot of sense at first glance, but try it. I was having exactly the same problem and it fixed it. I always use a password on my ssh keys and you should too. Commented Jan 25, 2012 at 20:56
  • 3
    This solution worked for me. It makes no sense but it works! (OS X Lion)
    – bbonamin
    Commented Mar 29, 2012 at 13:11
  • 2
    Wow, that makes zero sense whatsoever, but it sure corrected a lot of strange behavior on my system. Thanks. Commented Jun 18, 2012 at 15:28
  • 2
    For the life of me, I have not been able to figure out a solution for days now with the same issue and this fixed it for me. This does not make sense at all but it fixed my issue! Thanks, upvoted. Commented Aug 29, 2012 at 13:05
  • OMG thanks! Worked for me (mountain lion and using SourceTree) those dialogs were so annoying. Commented Aug 3, 2013 at 19:43

First, run ssh-add -K and check whether this fixes your problem.

If not:

  • Removed the rsa_id.pub file and regenerated a new one (must be in ~/.ssh/):

    ssh-keygen -y -f id_rsa > id_rsa.pub
  • Ensured permissions were set to 600 for both id_rsa and id_rsa.pub (must be in ~/.ssh/):

    chmod 600 id_rsa*
  • Ran the following command:

    ssh-add -K

After doing this, I was no longer prompted to give my private key password. This appears to actually put the private key password in the correct keychain location for OS X to use.

  • 7
    Was GOING INSANE until I ran across your "ssh-add -K" command. I don't believe how complicated OSX has made things. +1000
    – eduncan911
    Commented Aug 28, 2014 at 20:05
  • 4
    fwiw, I needed to chmod 600 (instead of 644) for it to work
    – kangax
    Commented Jul 13, 2015 at 17:00
  • 1
    Private Key with 644 is no bueno
    – xtian
    Commented Jul 17, 2016 at 2:22
  • 15
    ssh-add -K resolved my issue
    – Spechal
    Commented Sep 28, 2016 at 15:43
  • 2
    Not upvoting until chmod 644 is corrected to chmod 600, this is unsafe. Commented Dec 15, 2016 at 8:59

In my case ssh-add -K didn't do the trick, I had to specify the key:

ssh-add ~/.ssh/id_rsa
  • there is no -K option anymore. Your solution fixed it. I wonder why I needed to do this. Never had any password prompts.
    – DannyRe
    Commented Oct 6, 2016 at 17:47
  • Thanks! This is when OS X Sierra finally asked for my id_rsa password. Commented Dec 15, 2016 at 9:00
  • 2
    FWIW, the -K flag worked for me on Sierra 10.12.2 Commented Dec 21, 2016 at 7:46
  • Yep. I can confirm. -K does exist and fixes the issue in newest Sierra! Good job @nathancahill. Commented Jan 11, 2017 at 6:08

For macOS 10.12 Sierra ssh-add -K needs to be run after every reboot. To avoid this create ~/.ssh/config with this content.

Host *
   AddKeysToAgent yes
   UseKeychain yes
   IdentityFile ~/.ssh/id_rsa

Apple has added Technote 2449 which explains what happened.

Prior to macOS Sierra, ssh would present a dialog asking for your passphrase and would offer the option to store it into the keychain. This UI was deprecated some time ago and has been removed.

Edit: Apparently specifying a host and key isn't necessary. Just adding this is enough.

AddKeysToAgent yes
UseKeychain yes
  • This is what worked for me. At first I tried ssh-add -K, but the change would only work until I rebooted.
    – Gandalf458
    Commented Jan 5, 2017 at 13:43
  • I needed to put AddKeysToAgent at the top level of ~/.ssh/config. Commented Sep 19, 2017 at 6:23

You have to enter the passphrase for the private key somewhere, and OS X uses ssh-agent by default.

If you want to use ssh-agent but want to avoid the gui dialog box, you can use ssh-add to add the passphrase to the agent and then ssh as usual.

If do not want to use ssh-agent and instead have ssh prompt for the passphrase, then unset the SSH_AUTH_SOCK environment variable.

  • Thanks, Alrescha. Do you know if there is any way to store your private key password in the Mac OS X keychain permanently (not just for a single session)? Commented Aug 8, 2011 at 22:11
  • 3
    You can try 'ssh-add -K' in Terminal, but if there is a bug where checking the box does not work then this might not work either. I do not want my ssh passphrases stored in keychain so I have not tested this.
    – zzz
    Commented Aug 8, 2011 at 22:21
  • With ssh-add -K I do not have to enter my password to connect but the prompt still appears; I just dismiss it. Commented Aug 8, 2011 at 22:35
  • 3
    ssh-add -K is what you use to add your password to the keychain. If you don't enter your password, it can't get put on the keychain.
    – zzz
    Commented Aug 8, 2011 at 22:39
  • 1
    addendum: In both Lion and Snow Leopard, if I enter ssh-add -K, I get a prompt in Terminal – not a dialog box.
    – zzz
    Commented Aug 8, 2011 at 22:47

When you relax the permissions, the key is ignored. You won't gain anything by doing this.

If you want to use a key without having to enter a password every time, you have two options.

If you check the “Remember password in my keychain”, you won't have to type the password every time: it'll be stored in the keychain with all your other passwords. This is the recommended option.

You can create a private key file without a password. You can change your existing private key file so that it isn't password-protected (changing the password only affects the key file, not the key itself). From the command line, run ssh -p, enter the existing passphrase, and then leave the new passphrase blank. There is a security risk in having an empty passphrase: anyone who can access your private key file (for example by accessing your backups) can use it instantly.

  • Thanks for the answer, although one thing I forgot to mention--checking the "Remember password in my keychain" option has no effect: the dialog reappears the next time I connect. (Using an empty passphrase is not an option for me.) Commented Jul 24, 2011 at 17:52
  • 3
    Suggesting to replace a password protected key with a key without password is really an horrible idea...
    – Schmurfy
    Commented Aug 9, 2011 at 8:00

if you have added your private key to the source ~/.ssh directory, and you have entered ssh-add -K to add it to the keychain, and you have your public key contents copied to the .ssh/authorized_keys (for the correct account) file on the target server the dialog box goes away.

it's a tricky combination of files, permissions, locations, and commands so it can take time. i would not rush to a conclusion about bugs.


I have exactly the same problem on Lion (Mac OS X 10.7). I think is a bug... If the ssh authentication is password the client goes through public key first which is normal. However, even though you choose to save the passphrase on keychain (which is not required for the password authentication) next time when a new ssh connection is established you are asked again for the passphrase...

  • 1
    I also consider this as a bug, everything was working fine with snow leopard but everytime my computer come back from sleep the ssh key password is asked again although I checked "remeber it" the last time it asked ! Very annoying...
    – Schmurfy
    Commented Aug 9, 2011 at 7:59

There should be no need to regenerate your public keys. You can simply do these two commands:

chmod 0600 ~/.ssh/id_rsa.pub
ssh-add ~/.ssh/id_rsa

Basically, you need to tighten the permissions on the public key file, and you need to add your key to OSX authentication agent.


In the latest version of macOS (10.12.2 - Sierra) this is an easy fix. Just edit your ~/.ssh/config and enable the UseKeychain option:

Host *
UseKeychain yes

Save and solved.


This problem occurred on my OS X 10.7.4 system when ssh-agent died. A reboot fixed the problem. (You could try restarting ssh-agent, but I don't know if the Keychain is clever enough to pick up the new ssh-agent socket.)

  • This is what my problem fixed too after stumping around for an hour.
    – DannyRe
    Commented Oct 6, 2016 at 17:45
  1. Be sure that ~/.ssh/ is chmod 700.

  2. Be sure ~/.ssh/id* files are both chmod 600.

  3. Run /Applications/Utilities/Keychain Access.app and repair keychain.

  4. Logout. (Rebooting wouldn't be a terrible idea)

  5. Login

  6. If the problem persists, move your existing ~/.ssh/id* files to your Desktop and try generating new keys using ssh-keygen -t dsa -f ~/.ssh/id_dsa -C [email protected] and see if the new keys work better.

I'm on Lion, but IIRC Snow Leopard worked the same way.

ps - anyone who suggests using a blank ssh passphrase should be forced to wear a sign so other people know not to take advice from them.


Regenerating the public key does not seem to work for me (10.8), nor does generating a new SSH key. If I, for instance, run git pull after locking the login keychain a dialog box pops up to demand the password to the key instead of first attempting to retrieve the password from the login keychain.

However, if I kill ssh-agent first, I'm prompted for the login keychain password which then retrieves the SSH key password.

  • Hi, this looks like a separate question, rather than an answer for this question. Can you re-post as a new question?
    – Scot
    Commented Aug 12, 2013 at 3:43

Another interesting finding is if you copy & paste the content of the PEM file, you might have the ending missing the dash. So just remember to add the final line as,

  • Something similar is that when pasting an ssh key from something such as lastpass, it pastes all on one line. This seemed to be a problem for me, and once splitting the private key on whitespace back into the correct format, it worked. Commented Aug 25, 2016 at 14:31

I had to do the following steps in order to make it work.

# Change working directory
cd ~/.ssh
# Remove the old public key
rm id_rsa.pub
# Create a new public key
ssh-keygen -y -f id_rsa > id_rsa.pub
# Change permission
chmod 600 id_rsa*
# Add the key to ssh
ssh-add id_rsa
# Then finally test it (I used github)
ssh -i id_rsa.pub [email protected]

The final command should then output something like: Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.


I had the same problem. I seem to have fixed it by doing this.

1) Backed up by renaming to old the id_dsa and id_dsa.pub files.

2) Ran a new keygen with a blank passphrase.

Works with the launchctl period job monitoring a remote server as well as logging in from ssh in a terminal.

I have a quick function authme function in my terminal since I have the following in my .bash_profile

function authme {
ssh $1 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub

So a quick authme remoteserver.com will copy the new remote key over.

I think the bug is something to do with the passphrase not being converted over (my old Snow Leopard didn't have one at all).

Try that and see if it helps.

It didn't take more than 10 mins to do. I spent googling forever to see if there were any other mentions of this. This site was the only one!


  • Using a blank passphrase is not an option for me, unfortunately Commented Aug 8, 2011 at 19:09

I had a similiar problem. It turned out that the private key I was using was in a wrong format. I used PuTTY Key Generator on my Win machine and ssh on OS X expects a different format - Open SSH format.

It turned out that the tool I used to generate this key (PuTTY Key Generator) had an option to convert my priv key to the format required by Open SSH.

Simple as:

  1. Open PuTTY Key Gen
  2. Load your private key
  3. Select Convertsions > Export OpenSSH key.

The file you will save contains your original private key in proper (OpenSSH) format.


Please make sure that:

  1. You are using pem format for your private key. This is because Mac uses openssh client which works with pem. ppk is putty's proprietary format and is not compatible with openssh. You can easily convert ppk to pem using putty keygen, in case you have only ppk.
  2. The permissions on your pem file is 600. Private keys are only meant to be accessible only by their owner. So, if the permissions give read access to any one else, it will be deemed a security threat.

This should hopefully resolve the issue.


Use the .pem key rather than the .ppk key.

  • 1
    We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.
    – Tetsujin
    Commented Jul 15, 2015 at 6:30

You must log in to answer this question.

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