When working with different Linux/Unix servers, or when working with a Secure GIT repo, life is much easier after you have setup an SSH public & private keys. Setting up a public & private key is really pretty simple.
Start out by create a public & private key.
ssh-keygen -t dsa
You will now be prompted for a location and a few other options, the best anwser is the default, so just enter threw these. You will also be asked to create a password, creating a password at this step will require you to enter the password every time you wish to use the key, so best bet is to just enter threw those questions also. After you have created your new key, go into your “.ssh” folder (note the . before ssh) and copy your public key to remote servers.
cd .ssh
Next we want to rename the public key so we wont confuse it after sending it to the world.
cp id_dsa.pub matt_dsa.pub
Wonderful, now all we need to do is copy the public key to a remote server
scp matt_dsa.pub remote_server.example.com:~/.ssh
Note, the above example copies the public into the remote server’s .ssh folder, if the server dose not have a .ssh folder, you may need to create it. After the public key has been copied, we need to put it into the “authorized_keys” file.
cat matt_dsa.pub >> authorized_keys
and that’s it, just exit out of your remote server, and try to connect again, it should not ask you for a password, but just now connect. If you are using this your git account, just copy this key into the git’s users authorized_keys file.
Re: “You will also be asked to create a password, creating a password at this step will require you to enter the password every time you wish to use the key, so best bet is to just enter threw those questions also.”
This is actually extremely bad advice quoted above…
The whole purpose of protecting your key with a password is so that if the key is ever stolen or lost, it cannot be used by just anyone. If they do not know the password for the key, then it is useless to them until they can brute-force the password, which could take a while if you’ve chosen a good password. This gives you more than enough time to remove access for the compromised key before it can become a problem.
While it may seem inconvenient to have yet another password to remember, this can rather easily be made much more convenient by using one of the many keychain manager tools available to most modern operating systems so that you only have to type the password for the key once each login, or the password for the key is handled entirely automatically (such as is possible to set up using PAM authentication under Linux).
Point here is: Entirely unprotected private keys are simply asking for trouble sooner or later and should never be undertaken lightly. (One should think most carefully about how the key is to be used, how much access it is allowed, etc. before even thinking about creating/using such a key.)
Silver Knight,
I understand your argument on the text you quoted, but the name of the post is “SSH with no password”, thou you are not incorrect in your statements. There are many examples where a password less private key is necessary or required. The most prominent example I can think of is when using cron scripts or the like.
Thanks for your input, your option is welcome and a nice addition to this post.
-Matt
I fully agree that there are valid uses for a passwordless key. My only concern would be that without some warning pointing out the dangers of such a thing that many people coming from “less secure” operating systems might choose to use such keys without fully considering how to most safely go about it. Perhaps a future article covering some hints and tips on some basic security practices (file access permissions, limited usage keys, limited permission user accounts, logfiles and where to find them/how to view them, etc.) might be useful to such folk, and could easily be linked to from potentially risky ones such as this in the same way as this particular post is linked to from other posts here on your blog.