I regretted mentioning that I would get back with the key authentication in my previous SSH post since it did not look like I was getting to it. But thanks to the whim that I carry around..here it is..spent half a day today playing around with SSH key authentication. You may want to go over Part 1 in case you haven't...before proceeding.
In Part 1, I tried my hand at setting up an SSH connection based on basic fingerprint and then password authentication. Today spent half a day playing with SSH to try the public-key cryptography feature which is basically meant to erase the need to enter a password that has a lot of chances of being snooped.
Machines involved:
1. HP Pavilion dv6000 laptop (L1) (with Windows Vista :-( running and putty installed)
2. HP Pavilion desktop (D1) (Pentium 4!! really old..but good for playing such stuff): Installed the latest Ubuntu 12.04 LTS (codenamed Precise Pangolin) on it last week
3. An assembled Pentium dual core desktop (D2) ( running Ubuntu 11.10)
In my case, I have taken D1 to be my server, while L1 and D2 are client machines.
Brief:
To brief about the key cryptography, the client machine that wants to access the server runs a key pair generator (like PUTTYgen in Windows or ssh-keygen command in Ubuntu Linux). This generates a pair of keys, a public key that the client shares with the server machine and is stored in a specific location on the server and the private key that is stored on the client itself. Whatever communication takes place between the two, is encoded in terms of these keys and can be decoded only if one has the other key. Various types of keys supported include DSA and RSA.
Generating keys:
Windows:
On Windows (L1), I used the PUTTYgen to generate the key pair. I had selected the SSH-2 RSA (default) option and 2048 bit length (the more.. the harder to crack). Click on "Generate" to start the process. To bring in randomness to the number generation, it is good to give some random cursor movement as the app asks for. Once generated, save both the public key(no specific extension) and private key(.ppk).
Linux:
In Ubuntu, the SSH client comes pre-installed. The "ssh-keygen" command is used
amit@Hp-desktop-ubuntu-11:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/amit/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/amit/.ssh/id_rsa.
Your public key has been saved in /home/amit/.ssh/id_rsa.pub.
The key fingerprint is:
22:7b:9d:0e:62:a9:ec:3c:29:2c:1d:15:e0:d0:1e:b6 amit@Hp-desktop-ubuntu-11
The key's randomart image is:
+--[ RSA 2048]----+
|.... |
| o+ . |
| o.o . |
| E . |
| .. . S |
| . + o . |
|.. o= o o |
|o++o o o |
|.o=. . |
+-----------------+
Sending the public key to the server:
The public key needs to be stored in the file "authorized_keys" at the location
/home/[username]/.ssh/authorized_keys
Linux:
One has to run the command ssh-copy-id on the client (D2) as shown below:
amit@Hp-desktop-ubuntu-11:~$ ssh-copy-id amit@192.168.2.5
where 192.168.2.5 is the IP address of the server and "amit" is the user account that I would log into when connected. You will be prompted for the password of the user account on the server. Once that is provided, the file gets saved at the appropriate location on the server.
Windows:
In Windows, you can run the PSFTP application to transfer a file. Once transferred to the right location, ensure that the file is named as "authorized_keys" as is the requirement. Ideally this should have sufficed. But there is a complication here that took me some time and googling to realise. The text formatting that PUTTY provides for the public key is not directly compatible with OpenSSH format. An example:
PUTTY o/p:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20120514"
AAAAB3NzaC1yc2EAAAABJQAAAQEAx0O0uS31JUq4syTjV1Sufl3SNVfrV1dmPh8N
ZA6WSaAufBldoOwDTMutDZ1xcWwKkvK6xfbv6t9SX+BZOSRCpxrd6NPbPUZZxNra
94hKaO7depgn2OwCAsiMkYtbbta+k1q7rDu1Ri4mrfeFyl4dbnpphTnjF3quWMOF
zs7biu7YrBjgkYzGqbRdiFS4yH3Y03rFi4ZXPeioxfwaoka2enliKYmdeHDc0K8z
A0XBbnFrNYKKqPS7GIhGvwHJfEKt7IlxXhyL4/3prWfPd25Nd2uBmcGI3BCClTl2
ME+8UIsNtNEv7GshCj5o/VnlaOWxRyBeotp03H0i6gd/LIeXJw==
---- END SSH2 PUBLIC KEY ----
Key format expected by OpenSSH:
ssh-rsa(single space)AAAAB3NzaC1yc2EAAAABJQAAAQEAx0O0uS31JUq4syTjV1Sufl3SNVfrV1dmPh8NZA6WSaAufBldoOwDTMutDZ1xcWwKkvK6xfbv6t9SX+BZOSRCpxrd6NPbPUZZxNra94hKaO7depgn2OwCAsiMkYtbbta+k1q7rDu1Ri4mrfeFyl4dbnpphTnjF3quWMOFzs7biu7YrBjgkYzGqbRdiFS4yH3Y03rFi4ZXPeioxfwaoka2enliKYmdeHDc0K8zA0XBbnFrNYKKqPS7GIhGvwHJfEKt7IlxXhyL4/3prWfPd25Nd2uBmcGI3BCClTl2ME+8UIsNtNEv7GshCj5o/VnlaOWxRyBeotp03H0i6gd/LIeXJw==(single space)amit@HP-LAPTOP
The expected key should start with the string "ssh-rsa" followed by a single space then the actual key with no spaces after any character, a single space again in the end followed by an optional mention of the name of the user account that will be logged in as the client.
I spent quite some time debugging this. I kept getting the error "Server refused our key" and then prompting for a password which is what we do not want. One has to be very sure there are no extra characters like spaces, new lines etc. within the key due to the formatting that windows adds to the files. That was the issue in my case as also faced by another user:
Thanks to him, it was easy to debug...
Finally, firing an SSH session from client:
Windows:
This is the last step where you get to know if everything is correct or not. In Windows, open PUTTY application. You can configure a session and save it with the right IP address and user account on the server eg. amit@192.168.2.5. Under the menu for Category, go to Connection > SSH > Auth. Give the path of the private key file (.ppk) that was stored earlier. Once the connection is opened, if everything goes well, you should be greeted by the command prompt of the server machine. Else, you would be prompted for the account password since the key based authentication did not work out well.
Linux:
Run the command "ssh [IP address] -l [username]" and you should get the same result as mentioned above. For user "pradeep", the output would look as follows:
If you do mention a passphrase when generating the keypairs you will be prompted at this point for the same before logging you in. Else the log in will be unobstructed.
Now if you have more users logging to the same account on the server, the public keys get appended in the authorized_keys file. I think a linux client is much much easier to use since you avoid the incompatibility and manual editing of the key file and every client that does a "ssh-copy-id" automatically appends the keys in the file. No extra effort or editing needed...
Thats all folks!! (reminds me of looney tunes.. :-) )
By the way learnt one more thing in this process. People using Ubuntu might know that the first user they create automatically gets into the sudoers list, but every other user account is just a general user account with no sudo privileges. So if one wants to add a user to a sudoers group, first "su" to the sudo-capable account and run the command
sudo usermod -a -G sudo [username]
Try to log out and log into the specific user account which needs the rights. The "-a" flag is important since it tells that this group is to be appended to the already existing groups to which the user belongs to.
Also do check out the wikipedia page for more theory on this topic...
