Host based Authentication Using SSH

HOST-BASED AUTHENTICATION USING SSH

---

BACKGROUND

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

Host based authentication is situation of authentication takes place based on the host 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