How to use Public Key Authentication with SSH

How to use
Public Key Authentication
with
SSH

by

Donavon M. Norwood

CS265 Cryptography
Project
for
Mr. Mark Stamp
Professor of Cryptography
San Jose State University

11/25/2008

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.

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.

Part I
Cryptography

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.

cipher
plain text text
Symmetric Key

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

plain text cipher
text
Public 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 plain text

Symmetric Key

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.

cipher text plain text

Private Key

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 II
Authentication 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.

Part III
How 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:

#ssh-keygen -t rsa
Generating 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 rsa
Generating 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 key
ssh_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.

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+74fWo
f/ecQIy95DvtHVXnR3uJxGjO3/IyM1o5ZD9CC6ejjoYIFyUvKaEYy9zvIRKFwzG+Tv/cIyHFlRuPWftd6qy5RRsmWUVeAto
a8NjTOiVyUS3llTOVvovpujVCDgAeBdtt+SJt8K93wj3vTWqHAdxk7rB7u4RmiVqx8uUZ4VtwJPU/YTT4hQGTR69U2aW9
2awLbwXgrQIpu86+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:

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 IV
How 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 2
HostKey /usr/local/ssh/etc/ssh_host_rsa_key
HostKey /usr/local/ssh/etc/ssh_host_dsa_key
#Authentication:
PermitRootLogin no
StrictModes yes
MaxAuthTries 7
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Bob 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.

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.pub
The hash values should be the same on the SSH client and server if they are the same keys!

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.

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 he
is 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/bKZ
ZKNOMLOQhmCFEtwX7oJBys9v+X9jJUty6SAKqr7NQdETm5YMW3y5LMiKxjJcDIfvG7i
Fn66euEtIvfKiPcNvzlYqAmHBGigcqes8xyEg3eMoK/VmAqJTs6l1fYMyamJJRTLT3PKrp
8jY7AYDdB+fJ98EU6BoURsfE+XdOcKqwxewSVVY0zNSdCXi+UWxXm/FmF6VyFSUuU8
B9mU21MyR1nBs7lmwgAvBWY7g85uOXlHxOHQ2qufuETnmEZHMYCJOz9F2LQpaX7K
50h0ybXqr7PIUQ3Ac8Pd1xGgTo3oZnFZ3tTcyw== bob@nsa.gov

RSA public key for Bob

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.

PUBBob
{R}PUBBob
{h(S, R)}PUB172.16.1.80

{Data}S

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.

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 is
89: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/ecQIy95DvtH
VXnR3uJxGjO3/IyM1o5ZD9CC6ejjoYIFyUvKaEYy9zvIRKFwzG+Tv/cIyHFlRuPWftd6qy5RRsmWUVeAtoa8NjTOiVyUS3llTOVvovpujVC
DgAeBdtt+SJt8K93wj3vTWqHAdxk7rB7u4RmiVqx8uUZ4VtwJPU/YTT4hQGTR69U2aW92awLbwXgrQIpu86+M/
+TDC70NRaknixjivrpw==

DOES NOT MATCH the public key below
172.16.1.80 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA58a8EUJPSTRdVuSFGFTkJS262WsZMxxYfJ4VjSA0LC/yYvKUyow7ZXrnI4/N4P0xw9Q0lUlDp
/HJzo/2zuIsxv/R5CNGRbnU/jMuBg9vKk9YqYxRjDi5tzO99wutmmPJ/moF51zSYGBigdFEye9DdzN3EhLYSXAyamiWLRMmeY9QC/Cd
+KHOAZ5/rYTAh+BSLd+bJWtt09jLBLcs8Js5IlCfZEmB0EvsoX63X4sWIYphvermBYW3zixYL4DqqfpNsjh+VYAa9IjZdZqNioL53AjBqzy
ZmWtcJ1vThPy5SOTEDo6ffNFMeiJmKZCsFtmKKU1PIKq6zATctiPRXb7zpw==

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.

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 is
89: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.

How to use Public Key Authentication with SSH

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to How to use Public Key Authentication with SSH

Similar to How to use Public Key Authentication with SSH (20)

More from Don Norwood

More from Don Norwood (7)

How to use Public Key Authentication with SSH