HP-UX Secure Shell: Part 3 - Examples of key usage

Some examples of ssh in action.

To help demonstrate the purpose of the Host Key, let's initiate a ssh session:

client: ssh ctg701
The authenticity of host 'ctg701 (192.168.1.125)' can't be established.
RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ctg701,192.168.1.125' (RSA) to the list of known hosts.
jrice@ctg701's password: [enter your UNIX login password]
Last login: Thu Aug 22 16:02:52 2002 from client
ctg701:   

"ssh" is the command used to start an ssh client session in HP-UX. I have followed that with the name of the host. Basically, I have replaced telnet with ssh. Using the default configuration setting provided with HP-SSH:

  1. The client requests a session from the SSH server using port 22
  2. The server sends back its Public Host Key and if using SSH-1, its Public Server Key.
  3. The client checks its system's ssh_known_hosts file to see if the Public Host Key exists. If it exists, the host is authenticated. If it does not exist:
  4. The client checks its user's known_hosts file to see if the Public Host Key exists. If it exists, the host is authenticated. If it does not exist:
  5. The user is given a chance to add the Host Key to its known_hosts file. A fingerprint (or hash) of the host's key is displayed and the user is given the opportunity to manually authenticate the host. For example, in the above the following fingerprint was displayed:
    RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b
    

If you go back to where this RSA key was created, you will see that this is the fingerprint that was displayed. Users should actually look at this fingerprint and authenticate it before answering "yes". How could they authenticate it?

  1. They could call the system administrator and verify that the fingerprint is correct.
  2. The system administrator could push the fingerprint out to users via secure e-mail or in a hard copy format.

The user should be trained to always verify the fingerprint before acceptance. This prevents DNS spoofing or man-in-the middle attacks. Once this key is added to the user's known_hosts file, they will not be required to manually authenticate this key again unless the system administrator changes the SSH server's Host Key.

If the user gets a message that the key no longer matches, they should not simply accept the new key. They should be trained to manually validate the new fingerprint before accepting.

On HP-SSH the default for the client is to add the Public Host Key to the user's known_hosts file automatically when the user replies "yes" to the prompt (if no other key for the host exists). After the ssh session is completed the user has a new directory called .ssh and in that directory is the known_hosts file.

client: ll .ssh                                                         
total 4
-rw-r--r--   1 jrice      users          230  Aug 22 16:03 known_hosts
-rw-------   1 jrice      users         1024 Aug 22 16:03 prng_seed

client: more .ssh/known_hosts
ctg701,192.168.1.125 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAt2FJStwxsE/COE9vvE6COgS
s+Ow9i71zMqb75RtsVttMrxqZYboy9J4/STdQqrd3d5uEaBcq6F2Hi54A67Kizy1H2wwSj54S8sOfU5n
5jy3KzrJARNghs+A99Yku9kTdhD3J6Cld675Q7nDxhodcGvzcNmPsL2OIYW2SB3nFx3M=

The server that we made a connection to is listed in this file, automatically. And finally, the user is required to enter their UNIX login password.

What happens when we use "ssh" next time?

client: ssh ctg701                                                            
jrice@ctg701's password: 
Last login: Thu Aug 22 16:03:52 2002 from client
ctg701

This time we are only asked to enter the UNIX login password. The host was authenticated because the Host's Public Key was found in the user's known_hosts file. So, what has this accomplished? For starters, this session is encrypted. It was encrypted before the user entered their UNIX login password. Simply by following these steps, you have greatly increased your security by stopping passwords from being sent over the network in clear text. Further, we are using strong asymmetric cryptographic techniques to authenticate we are truely communicating with the correct host (as opposed to trusting a DNS lookup as authentication).

A look at the processes on the server shows that the ssh daemon spawns a separate process for the connection (3576). This process spawned the shell used by the user (3578).

root  2455     1  0 12:23:58 ?         0:00 /opt/ssh/sbin/sshd
root  3576  2455   0 16:22:32 ?         0:01 sshd: jrice@0
jrice 3578  3576   0 16:22:38 pts/0     0:00 -sh

If you want to make the migration to SSH seamless to users using the default configuration, you must have access to their clients. If all the users are on another UNIX host, this is easy, if the client is their individual PC, then this isn't as easy. If the client is another UNIX host, place the Host Public Key (of the remote/server system) in the /opt/etc/ssh/ssh_known_hosts file on the "client" computer. Next, replace telnet with a link to SSH.

mv /usr/bin/telnet /usr/bin/telnet.orig
ln -s /opt/ssh/bin/ssh /usr/bin/telnet

As this user (who has never used SSH) they are able to login without getting the prompt regarding host authentication because we have put the Public Host Key in the client's system ssh_known_hosts file:

client: telnet ctg701  (remember this is really ssh)
vking@ctg701's password: 
Last login: Thu Aug 22 17:24:53 2002 from client
ctg701:    

What happens if the ssh_known_hosts file does not exist and a client does not answer "yes" to the prompt?

client: ssh ctg701
The authenticity of host 'ctg701 (192.168.1.125)' can't be established.
RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.

The host verification will fail and the user will not be able to login.

Finally, for this article, let's take a look at a connection made in verbose mode. For this connection, the user, vking, does have a local known_hosts file.

client1: ssh -v ctg701                                                         
HP-UX port of OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.

.rhosts, .shosts, hosts.equiv, and shosts.equiv files are supported with SSH. The default configuration file disables these features because when used, all the systems that are trusted to each other are only as secure as the weakest system in the group. The use of these will be discussed in a future article.

debug1: restore_uid
debug1: ssh_connect: getuid 4002 geteuid 0 anon 1
debug1: Connecting to ctg701 [192.168.1.125] port 22.
debug1: temporarily_use_uid: 4002/20 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 4002/20 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/vking/.ssh/id_rsa type -1
debug1: identity file /home/vking/.ssh/id_dsa type -1

Next, the identity file is searched. In this example we do not have. This is covered in Part 2 of this series.

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1

The client and server agree to use SSH-2

debug1: Miscellaneous failure
debug1: No credentials cache file found
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

The client and server agree to which algorithms to use.

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 138/256
debug1: bits set: 1592/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ctg701' is known and matches the RSA host key.
debug1: Found key in /home/vking/.ssh/known_hosts:1
debug1: bits set: 1619/3191
debug1: ssh_rsa_verify: signature correct

The Public Host Key was found in the user's known_hosts file and the host is authenticated.

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.

The session key has been created and the session is encrypted. Finally, it will go through the various authentication methods.

debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: next auth method to try is external-keyx
debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: next auth method to try is gssapi
debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/vking/.ssh/id_rsa
debug1: try privkey: /home/vking/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: next auth method to try is password
vking@ctg701's password: 

Since we didn't have any of the other user authentication methods set up, it asked us to type our UNIX login password.

debug1: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64)
debug1: ssh-userauth2 successful: method password
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 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Thu Aug 22 17:51:29 2002 from client
ctg701:   

And we have success!

The following is the output of a network trace of the user vking (password = mypass4) logging on and issuing the bdf command using telnet:

   0: 76 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  v...............
   0: 6b -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  k...............
   0: 69 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  i...............
   0: 6e -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  n...............
   0: 67 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  g...............
   0: 0d 0a -- -- -- -- -- -- -- -- -- -- -- -- -- --  ................
   0: 6d -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  m...............
   0: 79 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  y...............
   0: 70 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  p...............
   0: 61 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  a...............
   0: 73 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  s...............
   0: 73 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  s...............
   0: 34 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  4...............
   0: 0d 0a -- -- -- -- -- -- -- -- -- -- -- -- -- --  ................
   0: 62 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  b...............
   0: 64 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  d...............
   0: 66 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  f........

The following is the output of a network trace of the user vking (password = mypass4) logging on and issuing the bdf command using ssh:

   0: 17 47 c1 2f 70 5e bf 1e 8a bf c8 5d ce 22 d9 33  .G./p^.....].".3
   0: 8a ae af f8 e5 19 63 37 db 27 9f 33 71 77 72 01  ......c7.'.3qwr.
   0: c4 0a 46 cb c9 fc d8 87 fe 8b 23 43 ee 9e d4 41  ..F.......#C...A
   0: a1 2e f4 25 82 56 ec bb b9 3a 13 4c d0 ed 21 99  ...%.V...:.L..!.
   0: d7 10 de 3b 52 fd 62 26 2e 8d 34 b0 ef 74 eb 61  ...;R.b&..4..t.a
   0: e1 50 25 3a 78 8e 22 76 09 48 e8 59 83 83 45 f6  .P%:x."v.H.Y..E.
   0: bd 2d aa eb 34 1e a7 23 de de ad a3 7e 9c f8 8d  .-..4..#....~...
   0: 05 f6 c6 e9 59 f2 2f b0 ab 2d 41 dd d0 11 3a 1f  ....Y./..-A...:.
   0: 13 84 af fc 8c e5 19 fd 22 f3 0c 05 a6 51 07 6f  ........"....Q.o
   0: f9 84 71 c1 77 97 e7 69 28 d0 8d 0e 4e 5e a9 1c 

So, which one do you think is more secure?


Chris Wong is a technical consultant and trainer for Cerius Technology Group, Inc. in Bellevue, WA. She is the author of the HP Press book HP-UX 11i Security. http://newfdawg.com


This was first published in September 2002

Dig deeper on Network Performance Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close