MacOS – Terminal won’t ask for passphrase and not stored in keychain

There is a lot of conflicting information I've read whenever I look up information on using ssh-agent (passphrase saving/reusing process) under Mac OS X. Most resources seem to suggest that simply issuing ssh-add -K will let you store your passphrase, and will automatically configure OS X to launch ssh-agent automatically and load your stored passphrase.

Note: Running ssh-add -K will only work if you have your private key file in one of the common locations, those locations being limited to: ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity. If the file is located anywhere else you should specify that path after the -K in the command above.

The reason you are getting the key file passphrase dialog when connecting to the second (key-less) server is likely because the default configuration of SSH servers is to use public key authentication first, and 'keyboard interactive' authentication second.

Because you have a public key with a standard name/location (~/.ssh/id_rsa), your OpenSSH client helpfully submits the private key in order to allow the server to match it against an allowed authorized_keys file.

There are a small handful of ways to prevent this, the easiest two being to pass a flag on the command line, or add it as a permanent configuration item in your ~/.ssh/config file.

1. When connecting to the secondary/key-less server, you can add -o "PubkeyAuthentication=no" when connecting. Something like ssh -o "PubkeyAuthentication=no" me@devserver2.

2. Open up ~/.ssh/config in your favorite text editor, create it first if you must, and enter the following:

   Host devserver2  
       User me  
       PubkeyAuthentication no
   

Now, if you simply type ssh devserver2 the username and pubkey configuration will be read in and used, and you should be prompted for your password and nothing else.

(Note: Replace devserver2 with the actual hostname of the server. Alternatively, pick a nice hostname, such as devserver2, and add a property between User and PubkeyAuthentication called 'Hostname' and put the name or IP address of the server there. Afterwards, you actually can simply type 'ssh devserver2' and all the configuration properties will work their respective magic.)

I had this same problem. However, when a generated a new password-less private key, using the following command:

ssh-keygen -b 1024 -t rsa -f id_rsa -P ""

I no longer saw the password prompt.

Additionally, ssh-add failed to add the old key, but added the new one as expected.

I generated the old key on Leopard in 2009, using what ever version of OpenSSL I had grabbed, built and installed back then (that Mac died, so I can't log in and check what I was running). Something about that key was incompatible with Lion's native SSL libraries.

I backed up my old key, so if anyone wants to suggest some checks, to identify the key's specific properties, let me what to check and I'll report back.

Another clue - I noticed that my old id_rsa.pub file had extended attributes. i.e. it's permissions flags looked like this r--------@ instead of r--------

xattr -l id_rsa.pub.old

returned:

com.macromates.caret: {
    column = 0;
    line = 1;
}

cruft left over from TextMate. I don't know if removing it would have fixed the issue without my having to replace the key. I think it's unlikely.

In case you (future reader) are seeing the same thing, you can remove the extended attribute as follows:

 xattr -d com.macromates.caret id_rsa.pub.old

You can stop TextMate from adding them by first exiting TextMate and then issuing this command:

defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1