How to Generate a Public Key With ssh

Useful ssh tricks

I don't like to let people log in to sensitive servers with passwords.  I generally disable this feature on servers I maintain.  I will explain.  ssh is used for many things.  I use the openssh flavor of ssh, but there are many other flavors.  For Windows, Putty is a popular ssh client.

 There are many things that you can do with ssh besides just establish a login session on a remote server.  scp and sftp are programs that allow you to connect to a server and copy files securely.  When you use plain old ftp to copy files, you are sending your passwords across the Internet in clear text, bad, mmkay.

One of the more useful things about a good ssh client is that it takes advantage of the features of a good ssh server (sshd).  A good ssh client will allow you do tunneling.  An example would be using ssh to connect securely into a Virtual Private Network, then using the tunnel created to secure a Windows Remote Desktop connection between the client and another machine on the VPN. A good ssh client can be used by other programs to connect to the ssh server, like in the case of svn, where you can include svn+ssh://yourhost/yourrepo instead of just svn://yourhost/yourrepo, which will also use the same ssh client.

There are lots of cool things you can do with ssh, but it all depends on getting the username and password set up properly so that authorized user (A), well call him "Joe",  can get into the server and copy files and check out things with subversion and tunnel remote desktop connections.  In a default kind of setup, you would create a user account on the server for Joe, then assign Joe a password.  Joe would then connect to the server, it would ask for his password, and he would enter it.  That's all good, unless, someone else had Joe's password.

Brute Force and Dictionary Attacks

When you use only usernames and passwords to protect your server, you are vulnerable to these types of attacks.  This type of attack involves attacker (X), well call him "Snidely", gaining access to your system by trying as many passwords as he can until one lets him in.  Snidely doesn't have to type these passwords in, he can just get passwords from the dictionary, or from a cracker library, and have an automated program keep trying until one works.   Your only protection against this type of attack, when you are using passwords, is to assign a "Login Limit".  This causes the account to be locked after a pre-defined number of unsuccessful login attempts, and shuts Snidely's little game down.

Public and Private Keys

Lucky for us, there is an even more secure method, Public/Private key exchange.  First I should explain what a public and private key is.  If Joe wants to send user (B), well call her "Sally", a secret  message, Sally can receive this message secretly by generating a public and private key.  Sally generates her public and private key, then she gives her public key to Joe.  Joe then writes the message and locks it up with Sally's public key.  Once the message is locked with Sally's public key, only Sally, with her private key can unlock it.  For an added level of Security ,  Sally was smart, and she also locked up her private key with a password, known only to Sally, when she generate the "Key Pair".

How to generate ssh  Public/Private Keys

Now let's say that Joe is the System administrator, and Sally wants in to the server.  What needs to happen is sally first needs to generate a public/private key pair.  If Sally has openssh, either in Cygwin (Under Windows), or openssh in Linux/Mac OS X, the ssh-keygen utility can be used as follows:

$ ssh-keygen -t dsa

If you do not add the "-t dsa" part, it will generate an rsa key.  Either will work, but I like DSA as RSA keys are not exportable outside the US, DSA keys are.  Also the default length of the key is 1024.  The length of the key determines how secure the key is.  The longer the key the more secure it is.  Theoretically nothing is "secure", when you talk about key lengths and whether or not it's secure you get into the whole argument about, is there enough computing power available to Snidely so that he can easily crack your key and gain access.  The longer the key, the more computing power Snidely will have to use to crack the key.  You can also specify a longer key (Up to 2048) if you use type RSA with "-t rsa".

After you hit enter, it will prompt you for where you want to store your files, it will look something like:


Generating public/private dsa key pair.
Enter file in which to save the key (/home/scott/.ssh/id_dsa):

You can enter a different filename, but I usually press enter, as the default is usually sufficient.  After you hit enter here, you will be prompted for a password.  This is important, you can choose to have no password (not recommended), or you can pick a password that locks up use of your private key.   As explained before, secret message locked up with this public key, will only be able to be read by using the private key.  Anyone in possession of the private key can de-crypt Sally's secret messages.  Any time you use this private key you will have to re-type this password.  This is important to note because when Sally tries to connect to the server, after Joe has installed her public key there, Sally will enter the same password she used to lock up her private key, NOT a password that is stored on the server.

Enter passphrase (empty for no passphrase):

After Sally has entered her passphrase, she will be prompted again:

Enter same passphrase again:

Then A nice little message with some additional randomart will display


Your identification has been saved in /home/scott/.ssh/id_dsa
Your public key has been saved in /home/scott/.ssh/id_dsa.pub
The key fingerprint is:
66:27:fc:27:8e:1d:43:ab:25:2b:3c:b7:8f:7b:16:69

If you look inside the id_dsa.pub file, you will see your public key.  It will look something like:

ssh-dss AAAAB3NzaC1kc3MAAACBAO2A0f//TUz1cx/23vRk7kfqEt81pQz6s0qbbjBaKPAn1eIbe7xHVogZNPdVhqWBMJ4xAWH5Fldayy4tJp5oDY0QqxsBVEvx81PUkmTD3cWMtysTaKqS6jjSNrGimRvL+xZf2jt4FvN1LQhFfeKI0Q1+MkoJ8GWD7ggmWC4/2GWhAAAAFQCJ2DgZMyN6AUTt+rW9Me2TZf4JhQAAAIAy2ehqfts19c+SNqKiIpII8kFI/u8N1tjKAV9sw2BDC5aJinqcoGGFXCI8J43ni4g/GPu+vAxWi2MPiGbw6MFnFvQRWdOPAjM5FJFU3mKqM3Vhk+29Qr25x/0cdDKh7hSPcmRRPTPTHwVEZwTErp8hG8JqFRlc0iSx/kMmLL6HCAAAAIEAiXy69U6zdYQitJfIMrc6dG61l/R7Rs+7Z9zsGpW5MmgyMMzAXU3gKO+0NEpUv9lMyDOqEYwEviU/0lyeesFmIl0T1/c/TOTtlgqpv9S5KAparVfkVXL3U4Gq7tNyzeGncbOd5u1tYdLh8dKgLPMtgmoHNzw+5m/Mc70TpVwLzZA= scott@monstro

All Sally needs to do is to e-mail the above text to Joe, and he'll know what to do.

What's a Joe to do? - Installing the public key on the server.

Now for Joe's part, he needs to take Sally's key, and if the /etc/ssh/ssh_client file has things in the standard place, and assuming home directories are in the standard place, and assuming that Sally's username is "sally".  Joe will put the above key (without any line-feeds or carriage returns) into:

/home/sally/.ssh/authorized_keys2

or

/home/sally/.ssh/authorized_keys

(Depending on how old your server installation is.  NOTE: I've seen both filenames needed in certain instances)

It is important that the ".ssh" directory in /home/sally be readable and writable, only by Sally.  In addition the authorized_keys file can only be readable and writable by Sally.  Just to be sure you can do the following commands as root.

$ sudo chmod 700 /home/sally/.ssh
$ sudo chown sally /home/sally/.ssh

$ sudo chmod 600 /home/sally/.ssh/authorized_keys2
$ sudo chown sally /home/sally/.ssh/authorized_keys2

If you leave out the above and the permissions are not correct, then Sally will not be able to log in, and Joe's authorized_keys file will be ignored.

How the ssh Authentication Handshake Works

I like this story, because it's the same way that Friend or Foe identification works in fighter aircraft.  So Sally want's to connect to the server.  Joe has done his part as administrator, and put Sally's public key into her authorized_keys2 file and Joe has also updated permissions on said files, using chmod and chown.  Sally can now use the command

$ ssh sally@joeserver.com

What happens next is that the ssh server, generates some random data.  It then uses Sally's public key, put on the server by Joe earlier, to lock up that random data.  It then sends the data to Sally.  Sally is prompted for a password, and she puts in the password she used to lock up her private key, when she generated the keypair.  Sally then unlocks the random data sent by the server, and sends it back, unlocked.  The server compare the unlocked version with it's pre-locked version and if they match, the server let's Sally in.

I get asked about the above quite a bit, and there is always consternation from the users when they have to generate keys, but it's a necessary evil.  Security, or convenience, pick one :)