Key-based authentication using ssh

As a foreword, it was pointed out to me my terms are all wrong. My bad, this page refers to key based authentication, not host based. I did have some notes one host based authentication, but I never got around adding them to this webpage. If you ended up here looking for host based, may I point you instead to this page. Just be aware that your paths may change depending on your flavour of OS.

So why would you want to set up key based authentication using ssh? Or better still, what is key based authentication anyway?

Key based authentication is situation of authentication takes place based on the public/private information, rather than with the more usual method of prompting for a password. This is very convient if a non-interactive process is trying to authenticate with a remote machine.

The old way was to use rsh and specify which users and machines were allowed to login remotely without a password. This is a bad way of doing it, firstly because the session passes as plain text, so is vunerable to snooping and secondly because it opens a large hole for potential IP spoofers.

SSH is the preferred way of setting up such connections now as it uses public and private key pairs to establish a secure connection. The keys and encryption methods make it extremely difficult for IP spoofers to generate a connection and since it is secure, you do not need to worry about data being sniffed.

The downside to establishing such a situation is a decrease in security. Once someone is on as that user on one machine, they are on all of the machines where it has been set up.

INSTALLING

Installation is a two step process, taking place on the two machines.

Machine "A" is the machine you want to connect from.
Machine "B" is the machine you want to connect to.

On Machine "A" (The from machine), generate your key pair using ssh-keygen

	ssh-keygen -t dsa

This will create two files:

	~/.ssh/id_dsa
	~/.ssh/id_dsa.pub

Log onto "to" machine :

Secure copy the id_dsa.pub key across to the local machine
Now look at the file /~.ssh/id_dsa.pub, if it starts with "ssh-dss", ie)

	ssh-dss AAAAB3NzaC1kc3MAAAC+CLO2M9OfcIjEaFBJ+cNAubJeCw8dtlHn1aKKN
	3i9p4YA4w+cXVvOoD6RVD2TLudLu5av8WLiePZemUws7F4Z6hj4XHVA09Oxzneetf
	9c4XoMiSLrkEaTzwFkQmefU3Jo4dQtK94rLqezd7ljs6/A91RpWSIQ0e4gYpl6fql
	sUx51AAAAFQDpN1MHahy7NuCTG7g6PmsZcMN47QAAAIBhV7zbd4tPi0IqJSk3d8K4
	VHb6udU+ofyTOM92E/vCO2fk392dqrxvo65ly5kYKlaMKFSYZ3GdFyAUJlf47hdra
	KgoxSR6xBqin9a8vq9q5EW+hMSXAJlD1/zeXydnmuxpVTTK/Lu9yTcEKuKsiHR9Ml
	XBmEqc5Cr/OQV83tehxQAAAIBIJp6sNFd4eFUxSQmfuMS56Cw5rbui8hDBNb5ViwS
	LGZFxuHquCyaqr81Y4dNecNUrlU+m6cXLvMY5SlspnBTuDCKGOIQmSsoiNnjOhYO4
	iWLKPN6hTYlmee+fqG2BJ24zE8sLB5t1KiqGKm4VUvaNGSDtDHMLeCz+qqH6H7LPI
	A== fred@somemachine.somewhere.com

Then append it to the file ./ssh/authorized_keys2 and ./ssh2/authorized_keys2

	cat id_dsa.pub >> ~/.ssh/authorized_keys2 
	cat id_dsa.pub >> ~/.ssh2/authorized_keys2

If it starts with "1024" Then append it to the file ./ssh/authorized_keys
Change the access permission on
- ~/.ssh/authorized_keys
- ~/.ssh/authorized_keys2
- ~/.ssh2/authorized_keys2
to user read/write only
```
 	chmod 600 ~/.ssh/authorized_key* 
	chmod 600 ~/.ssh2/authorized_key2 
```
Test - should be able to ssh from the "from" machine to the "to" machine without being prompted for a password.

TROUBLESHOOTING

What to look at if it doesn't work

Check the file ~/.ssh[2]/authorized_keys[2] do exist and have permissions of user read/write only:

machine:/home/fred/.ssh2%ls -al ~/.ssh2
total 12
drwxr-x--x    2 fred     users        4096 Sep  3 09:44 .
drwxr-xr-x   18 fred     users        4096 Sep  3 09:51 ..
-rw-------    1 fred     users         617 Sep  3 09:44 authorized_keys2

If they do not have 600 permissions, ssh may refuse to authenticate using the files. (Depends on the install of ssh).

Try running ssh in verbose mode to detect errors

 	ssh -v -l user hostname

or to generate more detail

 	ssh -vv -l user hostname

This should provide you with details on where the authentication is failing. A correctly implimented session generates the following output:

MachineA:/home/fred% ssh -v MachineB
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to MachineB [192.168.72.3] port 22.
debug1: Connection established.
debug1: identity file /home/fred/.ssh/identity type -1
debug1: identity file /home/fred/.ssh/id_rsa type -1
debug1: identity file /home/fred/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 145/256
debug1: bits set: 1587/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'MachineB' is known and matches the RSA host key.
debug1: Found key in /home/fred/.ssh/known_hosts:11
debug1: bits set: 1522/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try privkey: /home/fred/.ssh/identity
debug1: try privkey: /home/fred/.ssh/id_rsa
debug1: try pubkey: /home/fred/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x808bbc0 hint 2
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Tue Sep  3 12:36:15 2002 from MachineA
MachineB:/home/fred%

If ssh is upgraded or reinstalled on a machine, its public/private key pair will change. This will result in a warning when connecting between machine and may cause the authentication to fail.

If you look at the file ./ssh/known_hosts, that will provide you with a list of hosts and their keys that looks similar to this (lines have been truncated):

serverA 1024 35 140628275716542335018227053630138762374955
serverB 1024 37 168018214940842216534129401775597301238680
machine,192.168.32.1 1024 35 10756111653456055548443403148
websrv 1024 35 1075651116055548443031653434843152227399753
home 1024 37 109320343534525974618179046875249123021506535
10.3.2.1 1024 37 10920343597497631261817904687524902764535
10.3.2.2 1024 35 15939346411202234584533241802340556110376
serverC,192.168.10.2 ssh-rsa AAAAB3Nznty2btrsaC1yc2EAAABIw
machine_c ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAIEApqLnhgfwdWZgS
machine_b,10.3.2.27 ssh-rsa AAAAB3NzaC1mnhjtfc2EAAAABIwAAA

Find the entry for the hose that you are trying to connect to and delete its entry. This will force ssh to re-establish authenticity the next time it connects. If you then try to connect manually, like so:

serverA:/home/fred%ssh serverB
The authenticity of host 'serverB (192.168.44.2)' can't be established.
RSA key fingerprint is e3:c3:89:37:4b:94:37:d7:0c:d5:6f:9a:38:62:ce:1b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serverB' (RSA) to the list of known hosts.
Last login: Tue Sep  3 12:40:34 2002 from serverA

You will be prompted to accept the fingerprint and continue to connect. After that initial connection, the host authentication should resume working.

Conventions of this document:

This font indicates information typed by the user 
This font and colour represents data within files, either edited or produced
This font shows screen output

This font and color represent filenames
And this is the colour of normal text.