Network Management Strategies for the CIO
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:
- The client requests a session from the SSH server using port 22
- The server sends back its Public Host Key and if using SSH-1, its Public Server Key.
- 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:
- 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:
- 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
Requires Free Membership to View
- 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?
- They could call the system administrator and verify that the fingerprint is correct.
- 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
Join the conversationComment
Share
Comments
Results
Contribute to the conversation