SSH login without password in OS X and Linux

Tired of typing passwords logging to SSH servers you often access then switching to keys to authenticate will be a game changer. Complex passwords will in general provide a good level of security, but they are tedious and slow to type. Make sure these passwords are strong! Using passwords to authenticate also prevent you from running local scripts that automatic log into other computers (like servers), running tasks or perhaps you want to have a backup/copy running between your laptop and server(s). The good news is that's a simple solution to all of this. I use a machine running OS X in this example, but It is pretty much the same in most Linux and *nix.

SSH and keys, WTF

For you to be able to automatic (unattended) logoin to another machine must this machine have a copy of your machine public key. Your key is signed by what we call a passphrase (you really should use a passphrase). When you then access another machine that that have a copy of your public key, it prompt your for your password (passphrase), instead of the system user account password. You might argue that by doing did we not really fix the problem, we just shifted the problem and added another layer for confusion and complexety. But try to trust me, this was a move in the right right direction.

Copy your public key to the machine you want to log into

ssh public key
Details on keys and passphrase exchange cycle

Using a empty (none) passphrase

The most daring users, create a public key with a empty passphrase. This introduce a big security problem. If someone gain access to a copy of your private key, they will also have access to all the servers that trust/use this key.

Use a agent to propagate the passphrase

Keychain Access

A more secure way of solving this is using a program (ssh-agent) to propagate the passphrase. This solution is quite good, but like everything else it comes with a few drawbacks. You need to have your shell environment set up correctly, and only application with the correct environment setting is able to benefit from it. In OS X you are able avoid this problem simply by using the system utility "Keychain Access". It will store and propagate your passphrase, and in Leopard (10.5) Apple finally introduced native support for using Keychain Access also in terminal.

Other systems have other key managers. Do you need this is a command line is it normal to use ssh-agent and ssh-add.

ssh-agent /bin/bash

Setting it all up

OS X has native support for creating and storing pass phrases (Keychain access) so setting this up on your Mac is not that hard. Linux users that are reading this can also follow along then the only difference is what application you use to store the passphrase. Like an example will Gnome users normally use the Gnome Keyring application.

  1. Create your set of keys:
    Start up the Terminal application and run:

    ssh-keygen -t rsa -b 4096

    If you prefer a more modern key type is DCDSA a by now a broadly supported type. They key files created have a different name the for RSA but that is all you need to change. The following command create a 521bit key long

    ssh-keygen -t ecdsa -b 521

    ssh-keygen will the ask where to store the public key it is about to create. Normally the default suggestion works just fine (~/.ssh/ ssh-keygen then ask you to enter a pass phrase. Please use something secure here and please also remember it.

  2. Copy the public key to your SSH server
    Copy the newly created public key to the SSH server(s) you need to auto login into by using your favourite transport method. Please be careful not to overwrite ~/.ssh/authorized_keys if it already exist! This is how I personally copy the key, might not be your preferred method:
    • If authorized_keys exist:
      cat ~/.ssh/ | ssh "cat - >> ~/.ssh/authorized_keys"
    • If authorized_keys does not exist:
      scp ~/.ssh/
  3. Check your file permissions. A lot of different *nix system is picky when it comes to permissons. Setting your .ssh directory to 0700 and .ssh/authorized_keys to 0600.
      chmod 0700 ~/.ssh
      chmod 0600 ~/.ssh/authorized_keys


You should be all set. The very first time you now access the server by ssh, Keychain will prompt you for your keyphrase and then store it and you will never have to type it again.

Keychain store passphrase


Older post but still a good read, updated and added more information, language cleanup + added a few illustrations to it.

Excellent Post!!!! The exact piece of information I needed. As a newbie with very little Unix experience, this was the missing info I needed. Thanks so very much for this Post!

The best explanation and example I found, worked for me - thanks.

Worked perfectly. I added your link to a stackexchange question on this topic

this is a really concise description of how to set this up. very useful!

Hi Unfortunately this didn't work. The .pub contents were added correctly in to my authorized_keys on the server. But it still asks for a password. Any ideas? Thanks! :-)

I worked out why it didn't work for me. If you have more than one rsa file (e.g. ~/.ssh/fred_rsa etc) then you need to run ssh as follows: % ssh -i ~/.ssh/fred_rsa etc

Great tip Mike. Any separate key files needs to be told to ssh by using "ssh -i my_special_key_file". Other time when this do not work is normally related to permission of the .ssh directory and/or to your user home directory it self.

This isn't working for me either. It has something to do with my Mac as I can get this working every time on my Linux machines. I created an RSA key, added the public key to my authorized keys on the remote server, then when I ssh it keeps prompting me for my password. Even when I use ssh -i. Just for testing I even set the .ssh and all contents to 777. My user is the owner of the folder and files also... Any suggestions?

I was having issues getting connected just like Mike was. I tried everything. I even changed my .ssh and private key to 777 permissions. Still didn't work. Finally I got it figured out. DON'T change file permission to 777 even for testing. It makes life more difficult. So the original problem was that I had group sticky permissions on my home folder on the server. Then I had to go in and change my .ssh permissions to 700 and my private key to 600. This was the case on both server and local. Some tips for anybody else having issues, do a tail -f /var/log/auth.log and narrow down your error messages. Also, to Mike above, you can assign a key per host. Just create a config file in your .ssh folder and add: Host IdentityFile /path/to/private/key. This really helped me out since I'm using git and svn to upload code and this way I can specify a key for each server without the -i flag. See here for reference:

Excellent ! I just solve my problem in a breath. Thank you so much.

For me it didn't work. I've tried again and again - Major frustration :) Finally I have found out the problem - it seems that the home (~) permissions need to be checked also. For authorized_keys to work you need to have your home directory (~) writeable only by you. So be sure to check that if it doesn't work for you.

Does the name of the user in the user account on server have to be the same as the OS X account for this to work? How would you change this set up for the root account? I tried this on a Ubuntu 12.04 server that peruses the root account and used the "/root" directory as user directory connecting from the terminal in Mavericks with my local user (not root) . It doesn't seem to work at all with my local user and I see no sign of the Keychain app even getting a call.

@Mikael should work for root users but on ubuntu, first make sure you enabled the root account. I normally handle user name in my .ssh/config -file. host <alias> hostname user <user name>

Great, even worked on OS X 10.9 Mavericks. Thank you very much for this article

There is an article about SSH login without password which in very detailed explanation. which one you prefer dsa or rsa?

I liked DSA eclliptic curve due to high security even by using short keys though no all SSH implementations support it It also turnet out the some variations of it was not really that secure - This writeup (geeky warning) does more into details