How to usePublic Key Authentication

withSSH

by

Donavon M. Norwood

CS265 CryptographyProject

forMr. Mark Stamp

Professor of CryptographySan Jose State University

11/25/2008

page 2

About me:

My name is Donavon M. Norwood and I am a first year graduate student majoring in Computer Science at San Jose State University in San Jose, CA. Computer Science is a relative new major for me because I have a Bachelor of Science in Computer Information Systems from Grambling State University in Grambling, Louisiana. You see CS majors are math or should I say extremely more higher math oriented than CIS majors; now that I am in school, I see that the CS focus with computers tends to be with math, so not only am I learning cryptography in my CS265 Cryptography class, I am learning math as well. This could be tend to be very challenging especially when the instructor prohibits the use of high level scientific or any type of calculator. But enough about school.

I have worked for various companies including Earthlink Network when they began in Pasadena, CA way back around 1995. However my interest in Computer Security did not begin until 1999 when I was a contractor for Microsoft in Redmond, WA. As a Technical Support Engineer for one of the many unknown Microsoft products, I had my computer hacked TWICE!! I took a course in CCNA and obtained my CCNA in 2001, but unfortunately the economy in the Bay Area where I lived burst; so in essence I never used my CCNA professionally. So the next thing in Computer Security I tried was by majoring in Unix Systems Administration at Ohlone College where I was required to complete an internship in order to obtain my Associate of Science. I interned at LBNL (Lawrence Berkeley National Lab) in Berkeley, California. As a Unix Systems Administrator Intern at LBNL, I was responsible for using CUPS (Common Unix Printing Server) to install and configure printers throughout the LBNL on a CUPS print server; however the challenge of the project was that only the department in which a printer was located had access to print to a particular printer. After finishing the internship at LBNL, I interned for Ohlone College as a Adjutant Faculty member; here I completed a project that involved securing HTTP with HTTPS (SSL), GPG, SSH and VPN for my Linux Security class. The result of the project was that I installed and configured Apache Web server, DNS, SSL, SSH and Free Swan VPN on several Red Had 7 Linux Boxes and used network security tools like Ethereal to scan ports like SSL (443), SSH (22), and Free Swan VPN to verify that these security protocols actually were encrypting data. From there I worked for Wyse Technology, McAfee, and VMWare. I love Firefox browser security add-ons like McAfee SiteAdvisor which helps prevents spamming and phishing attacks, WOT (Web of Trust) which is like SiteAdvisor, Yahoo Toolbar with the CA (Computer Associate) Anti-Spy software; I also like to use security software like McAfee Internet Security Suite, nmap, ethereal, GPG, Wireshark, etc. So as you can read, I have some experience in Computer Security. I would not consider my self a Cryptographer or Cryptanalysis, BUT I would consider those who consider themselves Cryptanalysis to break a system built by me before I would consider myself a security expert; all I would need is a server running SSH (22), SSL (443), HTTP (80) Apache, IPTables, Oracle 10i, Squid Proxy Server in a VMWare ESX 3 Server environment with VMWare VMotion, DRS, Consolidated backup, etc. I'd like to learn how to secure this same environment using BGP and multiple VMWare ESX servers. I know cloud computing has become a big thing in the computer field, and with VMWare ESX 3 Infrastructure which includes connection via fiber channels to SAN makes cloud computing possible, but how to secure such an environment would be a challenge since physical servers are replaced by Virtual Machines running on a ESX 3 Server.

page 3

To secure this environment remotely, I would consider a VPN into each ESX 3 Server; and since each ESX 3 server can act as a router/firewall running BGP in remote locations, a good security measure would to connect each ESX 3 Server remotely to another ESX 3 Server in your BGP cloud computing via VPN; then you know for sure your data between remote locations is being protected or should I say encrypted as it crosses the for ever evil INTERNET public network between your remote locations, where hackers are waiting to obtain someone YOUR information for whatever reason. This is why we have guys like my instructor Mark Stamp who teaches my Cryptography class; well at least he is teaching us how to keep the bad guy away. Thanks Mr. Stamp! Please note that I AM NOT the security or network expert. Hopefully one day I will be!

What I will speak about:

Well the topic of the paper is How to use Public Key Authentication with SSH, however I need to touch on some other topics related to Cryptography which will lead me into explaining How to use Public Key Authentication with SSH; below are the topics I will discuss:

Cryptography

Authentication and Authentication methods

How to install and configure a RSA Server key pair

How to configure a SSH client to authenticate with public key cryptography to a SSH server

What type of Authentication method does SSH public key cryptography use?

How SSH uses public key cryptography to prevent man-in-the-middle attacks

Conclusion

Computer Security is a very broad topic so I will focus my attention on “How to use public key cryptography with SSH”, however I enjoy writing, so maybe I may surprise readers by speaking about other computer security related topics. To the readers who read this and ask, “What is SSH?”. I am assuming ALL readers who read this paper is familiar with SSH, but since I can not be 100% sure, before I get into the core of my topic “How to use public key cryptography with SSH”, I will give a brief explanation of what SSH is. SSH stands for for Secure Shell. It was created by Tatu Ylonen in 1995 while he was a researcher at Helsinki University of Technology. SSH was designed originally as SSH-1, but in 1996 it was replaced by SSH-2 which included security enhancements. SSH was designed to replace the TCP protocols rsh, ftp, and telnet which warranted many man-in-the-middle-attacks, because these protocols sent data like user name and passwords as clear text over the network; however SSH's design was to prevent these so called man-in-the-middle-attacks, and I will discuss how later.

page 4

Part ICryptography

Cryptography can be defined as the art and science of making codes. When I think of cryptography I think about something that needs to be kept secret. Cryptography has been around for a long time, in fact it was used in the Hieroglyphics in the Egyptian pyramids. Also the Hebrew Israelites of the Bible used a cryptographic system similar to the shift alphabet crypto system. Well today this cryptography is a very serious topic not ONLY in the computer field, but in other segments of business like government where a need to encrypt/decrypt data becomes a way of living. There are two very important types of cryptography:

Symmetric key cryptography which uses the same single key for encryption and decryption.

Asymmetric key cryptography which uses a public and private key for encryption and decryption. This type of cryptography is also known as public key cryptography.

When plain text data is encrypted with a Symmetric key or Asymmetric key, the resulting output is known as cipher text.

Example 1: shows how plain text in encrypted with a symmetric key

Example 2: shows how plain text in encrypted with a asymmetric key

Remember to note that in asymmetric key encryption, either the public or private key is used in encryption/decryption; what ever key was used for encryption, the other key is needed for decryption; for example in example 2 above, the plain text was encrypted with the public key, which would mean if the resulting cipher text needed to be decrypted, the corresponding private key must be used. A cryptosystem is what is used to encrypt data, and in example 1 above the cryptosystem used to encrypt data was symmetric key cryptography; in example 2 the cryptosystem used to encrypt data was asymmetric or public key cryptography.

cipher text

cipher text

Symmetric Key

Public Key

plain text

plain text

page 5

Example 3: shows how to decrypt the cipher text in example 1 back into plain text; notice the same symmetric key was used to encrypt/decrypt the same plain text/cipher text.

Example 4: shows how to decrypt the cipher text in example 2 back into plain text; notice that since the public key was used to encrypt the plain text in cipher text, to decrypt the same cipher text back into plain text, the corresponding private key was used.

Part IIAuthentication and authentication methods

Since SSH uses a client server model, which means a client requests a connection to a particular service/port on a remote server. SSH requires authentication, or in essence when a SSH client wants to connect to a SSH server, the client must authenticate with a user name and password. However since SSH uses public key cryptography, ssh clients are able to authenticate to a ssh server without using a password. We will talk about this later. However I would like to talk about authentication. Access control is basically defined as the access to system resources say on a computer. There are two parts to access control, authentication and authorization. Authentication is defined as determining whether a user should be allowed to a system resource. Since SSH involves a ssh client authenticating to a ssh server, lets consider the following ways a human can authenticate say to any machine (computer):

Something you know: like your user name/password

Something you have: like having a ATM card with a pin or a public/private key pair with a passphrase on the private key

Something you are: like having your thumb print authenticate to a computer.

Since the focus of this paper is How to use Public Key Authentication with SSH, I will explain how authenticating with public key cryptography with SSH will apply to all three methods of authentication above. From there I will get to the fun part of SSH, RSA. SSH uses both RSA and DSA as encryption algorithms, but I will focus only on RSA.

cipher text plain text

cipher text plain text

Symmetric Key

Private Key

page 6

Part IIIHow to install and configure a RSA key pair in SSH

Again assuming you have SSH installed, I will focus attention in my opinion is the core of SSH, generating a key pair for encrypting and decrypting data. SSH uses both RSA and DSA encryption algorithms, and with the new SSH v2, RSA seems to be the standard so I will focus on generating a RSA key pair. To you who have yet to install SSH, please refer to the following website: http://openssh.org/ and unzip the latest version of SSH; inside the install directory you will find a README or INSTALL file on how to install SSH. The SSH program ssh-keygen is what is needed to generate a new RSA key pair for SSH. Say for example a Red Hat Linux user by the name of Mark Stamp a security manager for the NSA (National Security Agency) is angry with two of his employee's Bob a security engineer & CISSP, and Alice a CISSP & CCIE for doing mediocre on the public key portion of the CISSP compared to his friends Trudy's employees at the CIA. To prove to Mr. Stamp that their knowledge of public key cryptography is better than the mediocre score they received on the CISSP, they would have to implement a real life situation in which public key cryptography is used. Both Bob and Alice know that public key cryptography is used in SSL, SSH, and VPN's, however Bob remembered one day he used FTP to upload Alice a file that contained the words “I-LOVE-YOU” in the file name, or basically the file was called I-LOVE-YOU-ALICE.txt; at the same time Mr. Stamp very concerned that Alice and Bob were not performing up to the level of a security experts at the NSA, was using Wireshark as a man-in-the-middle to snoop the data between Bob's computer and the FTP sever. Mr. Stamps saves the Wireshark scan results as 2weeksNotice.csv, and walked over to Bob's computer and then uses Excel to import 2weeksNotice.csv into an Excel spreadsheet. Mr. Stamp does an security analysis of the data, and points out to Bob in one of the packets from the scan results the name of the file he uploaded → I-LOVE-YOU-ALICE.txt plus his user name and password appeared in another packet in which Mr. Stamp analyzed. Bob embarrassed and Mr. Stamp angry, agree that both Alice and Bob need to learn the basics of security and not using NSA resources to goof off, should complete CISSP boot camp; fortunately they both completed it, but earned a mediocre grade on the public key cryptography portion of the CISSP. So this is where they currently are, trying to prove to Mr. Stamp that they can implement a public key cryptography system versus being fired. Bob knows that he and Alice have both Linux and Windows workstations, so he installs SSH on both Alice's and his Linux computer. Bob and Alice go online and do research on SSH, and find out that they could implement public key cryptography. Bob and Alice install SSH server on a Linux server running Red Hat Enterprise Server 4 with ip address 172.16.1.80. Bob on his SSH client 172.16.1.100 issues the following command to create his RSA public key pair:

page 7

#ssh-keygen -t rsaGenerating public/private rsa key pair.Enter file in which to save the key (/home/bob/.ssh/id_rsa):<enter>Enter passphrase (empty for no passphrase):<enter a passphrase and hit enter>Enter same passphrase again:<enter passphrase again and hit enter>Your identification has been saved in /home/bob/.ssh/id_rsa.Your public key has been saved in /home/bob/.ssh/id_rsa.pub.The key fingerprint is:25:b4:37:63:91:f3:b0:fc:fb:e2:6b:96:2d:da:f4:93 bob@nsa.gov

When Alice performs the same commands on her SSH client 172.16.1.101 we get:#ssh-keygen -t rsaGenerating public/private rsa key pair.Enter file in which to save the key (/home/alice/.ssh/id_rsa):<enter>Created directory '/home/alice/.ssh'.Enter passphrase (empty for no passphrase):<enter a passphrase and hit enter>Enter same passphrase again:<enter passphrase again and hit enter>Your identification has been saved in /home/alice/.ssh/id_rsa.Your public key has been saved in /home/alice/.ssh/id_rsa.pub.The key fingerprint is:34:c1:99:48:02:2f:60:76:50:9e:da:9f:67:d2:1d:60 alice@nsa.gov

Above are the keys that Alice and Bob generated will be used for public key authentication to the SSH server without a password, but I will speak about that later. After doing even more research Bob and Alice find out that the SSH generated a RSA public key pair for the SSH server as well when they installed SSH on server 172.16.1.80; Bob remembered that he used the “--prefix=” when installing SSH and installed SSH in /usr/local/ssh; when Bob enters the directory /usr/local/ssh/etc/ and does a “ls -l” he notices the RSA key pair of the SSH server 172.16.1.80 is listed as:

ssh_host_rsa_key – the RSA private keyssh_host_rsa_key.pub – the RSA public key

From his Linux SSH client Bobs types in:

#ssh -l bob 172.16.1.80

and receives the following message:

The authenticity of host '172.16.1.80 (172.16.1.80)' can't be established.RSA key fingerprint is d9:1g:0c:c3:6e:24:14:23:d9:a9:02:71:7d:e8:5b:4a.Are you sure you want to continue connecting (yes/no)? Yes <enter>Warning: Permanently added '172.16.1.80' (RSA) to the list of known hosts.

page 8

After he logs in, Bob remembered when he generated his RSA key pair for SSH it created a .ssh directory under his home directory of /home/bob on his SSH client 172.16.1.100. When Bob does a ls -l on /home/bob/.ssh, he notices the file known_hosts and when he views the contents of the file it displays the following in Example 5 below:

172.16.1.80 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0dghu45Q4wC9fv6jYseFSqN++o3vXLfQ6gJhMQXuoYLCoFDg7lAiJwrlVAo6iVZ98wjH051CM1Mabz2LY9oc6nft0SMbiPFsrG9REq3pXBOUmti+74fWof/ecQIy95DvtHVXnR3uJxGjO3/IyM1o5ZD9CC6ejjoYIFyUvKaEYy9zvIRKFwzG+Tv/cIyHFlRuPWftd6qy5RRsmWUVeAtoa8NjTOiVyUS3llTOVvovpujVCDgAeBdtt+SJt8K93wj3vTWqHAdxk7rB7u4RmiVqx8uUZ4VtwJPU/YTT4hQGTR69U2aW92awLbwXgrQIpu86+M/+TDC70NRaknixjivrpw==

Bob and Alice remember from their research that when a SSH client firsts makes a connection to a SSH server, a message like the one on the bottom of page 7 will appear, and then once the user accepts the connection, the SSH server stores a copy of it's public key ssh_host_rsa_key.pub into a file named known_hosts on the SSH client. The SSH server public key in known_hosts is what is used by the SSH client to encrypt data to the SSH server 172.16.1.80, which is then decrypted by the SSH server 172.16.1.80 ssh_host_rsa_key (RSA private key). Bob also remembered from his research that the message he saw at the bottom of page 7 was a feature in SSH that prevents man-in-the-middle attacks, but again I will get to that later.

Say Bob or Alice accidentally for this example destroy their SSH servers ssh_host_rsa_key (RSA private key); with the command: ssh-keygen -f /usr/local/ssh/etc/ssh_host_rsa_key -N '' -t rsa,

Bob and Alice will now have generated a new ssh_host_rsa_key (RSA private key) and ssh_host_rsa_key.pub (RSA public key) pair for SSH server 172.16.1.80. However when SSH clients connect to the SSH server, everybody will be angry because they are getting the weird message in the figure 1 below:

page 9

Obviously with Linux or any other Unix based system, the error message in figure 1 will be text based on the monitor. Since Alice and Bob generated a new RSA key pair, when the SSH clients makes a connection to SSH server 172.16.1.80, the error in figure 1 will show because the contents of the newly generated ssh_host_rsa_key.pub (RSA public key) does not match the ssh_host_rsa_key.pub (RSA public key) key data in Example 5 in which the SSH server stored in Bob's known_hosts file when Bob first connected to the SSH server. Again I will talk more about man-in-the-middle attacks on SSH later.

Part IVHow to configure a SSH client to authenticate with public key cryptography to a SSH server

In part III I explained how Bob authenticated with his password to connect to the SSH server 172.16.1.80. Since authentication requires something you know like a password for example, Bob was able to use this authentication method to connect to server 172.16.1.80. However Bob is still a bit concerned about when Mr. Stamp snooped his password when he sent Alice the file I-LOVE-YOU-ALICE.txt via ftp. From their research on SSH Bob and Alice find out that they can authenticate to SSH server 172.16.1.80 with public key authentication without sending their username and password. Bob and Alice know that on the SSH server 172.16.1.80, that they need to configure the server for public key authentication. Below are the entries in SSH servers 172.16.1.80 sshd_config file, the main SSH server configuration file:

ListenAddress 172.16.1.80:22 #HostKeys for protocol version 2HostKey /usr/local/ssh/etc/ssh_host_rsa_keyHostKey /usr/local/ssh/etc/ssh_host_dsa_key#Authentication:PermitRootLogin noStrictModes yesMaxAuthTries 7RSAAuthentication yesPubkeyAuthentication yesPasswordAuthentication yes AuthorizedKeysFile .ssh/authorized_keysBob and Alice added the configurations to the sshd_config file above; specifically every configuration below #Authentication was added to sshd_config for public key authentication. The option PermitRootLogin specifies whether root can log in using ssh. Never say yes to this option. The option StrictModes specifies whether ssh should check user's permissions in their home directory and rhosts files before accepting login. This option must always be set to yes because sometimes users may accidentally leave their directory or files world-writable. The option RSAAuthentication specifies whether to try RSA authentication. This option must be set to yes for better security in your sessions. RSA uses public and private key pairs created with the ssh-keygen utility for authentication purposes.

page 10

The option PasswordAuthentication specifies whether we should use password-based authentication. For strong security, this option must always be set to yes. The option AuthorizedKeysFile specifies the location of the file used to store a users public key data when using public key authentication; this file is stored in the users .ssh directory on the SSH server.

From part III, Alice and Bob created public/private RSA key pairs on their SSH clients. The name of the private key file is id_rsa, and the public key file name is id_rsa.pub. For public key authentication to work on SSH server 172.16.1.80, Bob and Alice must copy their public key to the .ssh/authorized_keys file in their home directory on the SSH server 172.16.1.80. Bob feeling a bit secure and comfortable using SSH using scp instead of ftp, from his home directory on his SSH client issues the following command:

#scp .ssh/id_rsa.pub bob@172.17.1.80:/home/bob/.ssh/authorized_keys

Like wise Alice from her home directory on her SSH client issues the following command:

#scp .ssh/id_rsa.pub alice@172.16.1.80:/home/alice/.ssh/authorized_keys

Now that Alice and Bob are configured for public key authentication, they still need to perform some additional steps needed before they can authenticate. From his SSH client Bob types:

#ssh bob@172.16.1.80

and Bob receives a message like the following below:

Enter passphrase for key '/home/bob/.ssh/id_rsa':

When Bob enters his passphrase, he is ready to use public key cryptography, plus Bob has now authenticated via SSH with public key authentication. Bob now knows for sure that Mr. Stamp is not able to use Wireshark to tap the network for his password, because with public key authentication there is no password sent over the network, so Mr. Stamp will be snooping with Wireshark for absolutely nothing. Here is how public key authentication with SSH works. When Bob configured his authorized_keys file, he scp the contents of his .ssh/id_rsa.pub on his SSH client 172.16.1.100 to bob@172.17.1.80:/home/bob/.ssh/authorized_keys on the SSH server 172.16.1.80; before Bob wants to authenticate via SSH to 172.16.1.80, he should first enter:

# ssh-keygen -lf ~/.ssh/known_hosts Inside the known_hosts file is the the public key of 172.16.1.80, so when Bob does the following command on the SSH server 172.16.1.80:

# ssh-keygen -lf /usr/local/ssh/etc/ssh_host_rsa_key.pubThe hash values should be the same on the SSH client and server if they are the same keys!

page 11

Say Bob did not want to input a passphrase each time he wanted to authenticate via SSH using public key authentication, because Mr. Stamp is known to peep over peoples shoulders to gain access to their passwords. Bob could use the following command:

# exec ssh-agent bash (our the shell of your choice)

Since Bob is using the bash shell, he could put the command eval `ssh-agent` in /home/bob/.bash_profile and eval `ssh-agent -k` in /home/bob/.bash_logout which would start/stop the ssh-agent; without it Bob would have to enter the above command before he could add his passphrase in the cache in SSH. From there Bob runs the command:

# ssh-add ~/.ssh/id_rsa

This command above will provide the following output:

Enter passphrase for /home/bob/.ssh/id_rsa:

Once Bob enters the correct passphrase he will get the message below:

Identity added: /home/bob/.ssh/id_rsa (/home/bob/.ssh/id_rsa)

With the above command it will prompt Bob to enter his passphrase for his private key id_rsa; this command will cache Bob's passphrase, so when Bob wants to use public key authentication to 172.16.1.80, he will not be prompted for his passphrase each time. However it is also recommended that when Bob leaves his SSH client open, he should run the command:

# ssh-add -d ~/.ssh/id_rsa

or

# ssh-add -D

which will remove Bob's passphrase from the cache, or the second command which will clear all cached passphrases. So say Mr. Stamp seeing Bob's SSH client available and tries to authenticate from Bob's machine to SSH server 172.16.1.80 with the following command:

#ssh bob@172.16.1.80

it will prompt for Bob's passphrase. Even if Mr. Stamp tried the following command:

# ssh-keygen -p -f ~/.ssh/id_rsa

which would change the passphrase for Bob, Mr. Stamp will fail because with public key authentication, Mr. Stamp will need to know the old passphrase before he can change to a new passphrase.

page 12

What type of Authentication method does SSH public key cryptography use?

Mr. Stamp in his book “Information Security” says that authentication is defined as follows:

1) Something you know like a password

2) Something you have like a ATM with a pin, or a private key with a passphrase.

3) Something you are like a public/private key pair or a fingerprint.

In our scenario, Mr. Stamp fulfills authentication step 2, because he has something to authenticate with (Bob's private key), however he does not know the passphrase to authenticate with Bob's private key, therefore he would not be able to prove in step 3 that heis actually the key fingerprint in /home/bob/.ssh/authorized_keys to authenticate to SSH server 172.16.1.80 with public key authentication. Even if Bob's key is compromised by Mr. Stamp, it would useless because he does not have the passphrase to the key itself. Remember from page 7 when Alice and Bob created RSA public/private key pairs with passphrasses, they created a unique fingerprint (key pair) with a passphrase. Since authentication is defined as:

1) Something you know like a password/passphrase

2) Something you have like an ATM with a pin, or a private key.

3) Something you are like a fingerprint or a private/public key pair.

We know that SSH authentication uses all three authentication methods because when Bob authenticated with public key authentication, he had a key with a passphrase which would satisfy authentication methods 1 and 2; and since Bob copied his /home/bob/.ssh/id_rsa.pub to the /home/bob/.ssh/authorized_keys, the data contained in this file will prove authentication method 3, because without it, the SSH server has no clue who Bob is, so if Bob wanted to authenticate to SSH server 172.16.1.80, he would have to use his user name/password for authentication. The key in which the server 172.16.1.80 recognizes as Bob is as followed below:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqyzf/4KEMEsVOA/zeJNnOqZJc1NaCBPvm/bKZZKNOMLOQhmCFEtwX7oJBys9v+X9jJUty6SAKqr7NQdETm5YMW3y5LMiKxjJcDIfvG7iFn66euEtIvfKiPcNvzlYqAmHBGigcqes8xyEg3eMoK/VmAqJTs6l1fYMyamJJRTLT3PKrp8jY7AYDdB+fJ98EU6BoURsfE+XdOcKqwxewSVVY0zNSdCXi+UWxXm/FmF6VyFSUuU8B9mU21MyR1nBs7lmwgAvBWY7g85uOXlHxOHQ2qufuETnmEZHMYCJOz9F2LQpaX7K50h0ybXqr7PIUQ3Ac8Pd1xGgTo3oZnFZ3tTcyw== bob@nsa.gov

RSA public key for Bob

page 13

Note that Bob's SSH clients IP address is 172.16.1.100. Without this key being in Bob's /home/bob/.ssh/authorized_keys file, the server 172.16.1.80 would not authentic Bob with public key authentication; also without this key being in /home/bob/.ssh/authorized_keys, this would prevent method 3 of the types of authentication being 'Something you are'; and in this case, the key in /home/bob/.ssh/authorized_keys proves something you are. How do we know? Well look at the contents of /home/bob/.ssh/authorized_keys above RSA public key for Bob on page 12.

Bob@172.16.1.100 SSHserver@172.16.1.80

In the above diagram:

1. Bob sends the SSH server 172.16.1.80 his public key

2. Server sends a challenge 'R' to the Bob, encrypted with the Bob's public key

3. Bob decrypts message, adds the session key 'S', and performs a hash on the result. This value is sent to the server as an authenticator

4. The SSH server 172.16.1.80 also calculates the hash value of the combined message and session key, and compares the result to the authenticator

5. Bob is authenticated to the server if authenticator and server- calculated hash match; all data between Bob's SSH client 172.16.1.100 and SSH server 172.16.1.80 is encrypted with Session Key 'S'.

A session key is a randomly generated, symmetric key for encrypting the communication between the SSH client and server. It is shared by the two parties in a secure manner during the SSH connection setup, so that an eavesdropper cannot discover it. Both sides then have the session key, which they use to encrypt all communication. The key is destroyed when the session ends.

PUBBob

{R}PUBBob

{Data}S

{h(S, R)}PUB172.16.1.80

page 14

How SSH uses public key cryptography to prevent man-in-the-middle attacks

Mr. Stamp a bit concerned that Bob and Alice have gotten somewhat ahead of learning public key cryptography, decides to build himself a SSH server with ip address 172.16.1.80, the same ip address as Bob and Alice's SSH server. Bob and Alice not aware of this, decide to scp a file named weWantaRaise.txt to their SSH server 172.16.1.80. When Alice enters the following command from her SSH client 172.16.1.101:

#ssh -l alice 172.16.1.80

she gets the following message below:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is89:f2:4c:1b:4e:bf:ae:5e:95:a4:f3:31:1f:62:6c:92.Please contact your system administrator.

Since Mr. Stamp is a nice guy, he tells Alice what he did. Both Alice and Bob know from their research that SSH prevents man-in-the-middle attacks with public key authentication/cryptography by placing the SSH servers /usr/local/ssh/etc/ssh_host_rsa_key.pub in the .ssh/known_hosts on the SSH client; if these two keys do not match, one will get the message above; Alice got the message above because the SSH server 172.16.1.80 public key below in .ssh/known_hosts on Alice's SSH client 172.16.1.101

172.16.1.80 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0dghu45Q4wC9fv6jYseFSqN++o3vXLfQ6gJhMQXuoYLCoFDg7lAiJwrlVAo6iVZ98wjH051CM1Mabz2LY9oc6nft0SMbiPFsrG9REq3pXBOUmti+74fWof/ecQIy95DvtHVXnR3uJxGjO3/IyM1o5ZD9CC6ejjoYIFyUvKaEYy9zvIRKFwzG+Tv/cIyHFlRuPWftd6qy5RRsmWUVeAtoa8NjTOiVyUS3llTOVvovpujVCDgAeBdtt+SJt8K93wj3vTWqHAdxk7rB7u4RmiVqx8uUZ4VtwJPU/YTT4hQGTR69U2aW92awLbwXgrQIpu86+M/+TDC70NRaknixjivrpw==

DOES NOT MATCH the public key below172.16.1.80 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA58a8EUJPSTRdVuSFGFTkJS262WsZMxxYfJ4VjSA0LC/yYvKUyow7ZXrnI4/N4P0xw9Q0lUlDp/HJzo/2zuIsxv/R5CNGRbnU/jMuBg9vKk9YqYxRjDi5tzO99wutmmPJ/moF51zSYGBigdFEye9DdzN3EhLYSXAyamiWLRMmeY9QC/Cd+KHOAZ5/rYTAh+BSLd+bJWtt09jLBLcs8Js5IlCfZEmB0EvsoX63X4sWIYphvermBYW3zixYL4DqqfpNsjh+VYAa9IjZdZqNioL53AjBqzyZmWtcJ1vThPy5SOTEDo6ffNFMeiJmKZCsFtmKKU1PIKq6zATctiPRXb7zpw==

on Mr. Stamps man-in-the-middle SSH server 172.16.1.80. Since the keys do not match Alice or Bob will get the above warning message.

page 15

When Alice does a ssh-keygen -lf ~/.ssh/known_hosts on her SSH client 172.16.1.101 she should get:

da:1f:0c:c9:6e:2c:14:23:d9:99:05:72:7d:08:5b:4a

which is the key fingerprint to her and Bob's SSH server 172.16.1.80 public key; however since Mr. Stamp also too configured a SSH server with ip address 172.16.1.80, when Alice tried to connect to 172.16.1.80, she got the following warning message

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is89:f2:4c:1b:4e:bf:ae:5e:95:a4:f3:31:1f:62:6c:92.Please contact your system administrator.

Because Mr. Stamps SSH server 172.16.1.80 public key fingerprint is

89:f2:4c:1b:4e:bf:ae:5e:95:a4:f3:31:1f:62:6c:92

Conclusion

Mr. Stamp though totally not impressed by Bob's and Alice's accomplishments decides to let Bob and Alice stay working at the NSA. In fact Mr. Stamp decided to take a two week vacation so he could brag to his friend Trudy at the accomplishments Bob and Alice made with SSH Public Key Authentication. Bob and Alice now can send encrypted 'I LOVE YOU' letters via SSH without worrying about the prowling eyes of their boss Mr. Stamp and live happily every after. They also learned how to authenticate via SSH with out sending their passwords over the network, and also learned that using public key authentication with SSH will prevent man-in-the-middle attacks. With the command ssh-keygen -lf ~/.ssh/known_hosts, they have learned that they can verify the identity of a SSH server in case they were ever involved in a man-in-the-middle-attack again. Bob and Alice also concluded that with SSH Public Key Authentication, they used all three authentication methods, something you know in their case a passphrase, something you have in their case a public/private key pair and something you are like a fingerprint in their case a public key fingerprint. With the help of their boss Mr. Stamp, they were able to do a man-in-the-middle attack to test and see if using SSH Public Key Authentication prevented this type of attack, in which it did. Lastly, Alice and Bob learned that when they send data between their SSH client and SSH server 172.16.1.80, all the data will be encrypted with a Session key which is then discarded after the termination of a SSH session.