Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

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:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
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.

share|improve this question

10 Answers 10

up vote 29 down vote accepted

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.

share|improve this answer
1  
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. –  Alex Recarey Jan 25 '12 at 20:56
2  
This solution worked for me. It makes no sense but it works! (OS X Lion) –  bruno077 Mar 29 '12 at 13:11
1  
Wow, that makes zero sense whatsoever, but it sure corrected a lot of strange behavior on my system. Thanks. –  Warren Pena Jun 18 '12 at 15:28
1  
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. –  Danny Englander Aug 29 '12 at 13:05
    
OMG thanks! Worked for me (mountain lion and using SourceTree) those dialogs were so annoying. –  Sebastian Sastre Aug 3 '13 at 19:43

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.

share|improve this answer
    
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)? –  titaniumdecoy Aug 8 '11 at 22:11
2  
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 Aug 8 '11 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. –  titaniumdecoy Aug 8 '11 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 Aug 8 '11 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 Aug 8 '11 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.

share|improve this answer
    
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.) –  titaniumdecoy Jul 24 '11 at 17:52
3  
Suggesting to replace a password protected key with a key without password is really an horrible idea... –  Schmurfy Aug 9 '11 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.

share|improve this answer

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...

share|improve this answer
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 Aug 9 '11 at 7:59

Something that finally worked for me was this :

  • 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 0644 for both id_rsa and id_rsa.pub (must be in ~/.ssh/):

    chmod 644 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.

share|improve this answer
    
Was GOING INSANE until I ran across your "ssh-add -K" command. I don't believe how complicated OSX has made things. +1000 –  eduncan911 Aug 28 at 20:05
  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 you@youremail.tld and see if the new keys work better.

In case it helps, here's how my Keychain entry appears:

ssh1 ssh 2

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.

share|improve this answer

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.)

share|improve this answer

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.

share|improve this answer
    
Hi, this looks like a separate question, rather than an answer for this question. Can you re-post as a new question? –  Scot Aug 12 '13 at 3:43

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

#~/.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!

Owain.

share|improve this answer
    
Using a blank passphrase is not an option for me, unfortunately –  titaniumdecoy Aug 8 '11 at 19:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.