Lab - SSH and OTP authentication

In this guide you are going to configure and explore the use SSH (Secure Shell) secure sessions. You will need two Linux computers (one virtual machine and one physical laptop is adequate). One computer, M1, will have the role of server. If this is a Virtual Machine, and you are in the University wireless network, you will need to add two network interfaces: one for internet access using NAT, and another for communication with the host (Host Only).

The other computer, M2, will have the role of client, and you can use your laptop.


In this section you are going to configure the server (M1), the client (M2) and the local network where both connect.

Server Computer(M1)

Server computer must have two network interfaces, one to connect to an external network, to connect to the Internet, and the other to connect to an internal network, to communicate with M2.

External network interface configuration

Connect on of the server (M1) network interfaces (e.g., interface eth0) to an external network that provides connection to the Internet (Wifi). If your server is a virtual machine, in the virtualizer (e.g., VirtualBox) you must attach the virtual interface to Bridged Adapter or NAT. We will designate this interface as the external interface.

At the operating system level, using the Network Manager, you must configure the interface to use DHCP to get its network configuration. Confirm that the internet correctly receives the network configuration and that the computer is connected to the Internet.

Services’ configuration

Check if the Telnet and SSH services are installed and enabled in the server computer (M1). For that, use the following command to check if the TCP ports used by those services are available to accept connections.

netstat -atn

With the following commands you may install and configure the SSH and Telnet services in a Linux computer. Use those that are adequate to install the services missing in M1.

Start by updating the repositories with:

    sudo apt update

Install the Telnet service (telnetd), using:

sudo apt install telnetd

If you need to restart the Telnet service, you may use the command:

sudo /etc/init.d/openbsd-inetd restart

Install the SSH service with the following command:

sudo apt install openssh-server

If you need to restart the SSH service, you may use the command:

sudo service ssh restart

Check that both services are up and running.

You also need to install Wireshark because you will need to capture and analyse packets exchanged between M1 and M2 computers.

Internal network interface configuration

The second network interface of M1 (e.g., eth1) will connect to an internal network to which M2 computer will also be connected. If your server is a virtual machine, in the virtualizer, you must attach the virtual interface to Host Only. We will designate this interface as the internal interface.

Configure the interface as using dynamic addressing with DHCP. After the Virtual Machine starts, the interface should have an address similar to In your laptop you can connect to this interface using the IP address.

Client Computer (M2)

By default, SSH and Telnet client applications come installed in most Linux distributions. In case you need to install any of them, you may the following commands (use the ones that apply):

sudo apt-get install telnet

and/ or

sudo apt-get install ssh

Note: A client application for Windows is PuTTY, available at It is both a Telnet and SSH client.

Inspecting network traffic

In the client computer, using Wireshark start a capture of the traffic exchanged between the server and the client. Apply a filter to only observe Telnet and SSH packets, by applying the following rule in the filter window:

telnet || ssh

With this filter applyed, Wireshark will show all the SSH and Telnet packets exchanged between server and client computers.

Inspecting Telnet traffic

In the client computer (M2), with an active traffic capture, start a Telnet session to the server computer (M1). Login and and list the contents of the root folder, using the command:

ls /

Close the Telnet session, stop the Wireshark capture and analyse the captured packets. Can you observe, in the captured packets, the contents of the root folder you listed above?

Still analysing the captured Telnet traffic, can you find the password you used to login when starting the Telnet session in the server computer (M1)?

What do you conclude regarding the security of the Telnet protocol?

Inspecting SSH traffic

In the client computer start a new capture and apply a filter to only show the captured SSH packets.

In the client computer (M2) start an SSH session with the server computer (M1). In case it is the first connection to that server, the server will authenticate presenting its public key and you are asked if you trust the key and want to save it. Say yes to proceed. Login into the server and list the contents of the root folder using the command:

ls /

Close the Telnet session, stop the Wireshark capture and analyse the captured packets. Can you observe any data in the packets. What do you conclude about the general security of SSH, comparing to Telnet?

Authentication in SSH

In this section you are going to analyse how the server and clients and clients authenticate in the SSH protocol. It is assumed that SSH configuration files are in their original state, i.e., no change has been made to the SSH configuration.

Server autentication

In the first interaction of an SSH client with an SSH server, the client must validate the server identity. For that purpose, the SSH server send its public key to the client and the respective fingerprint in presented to the user, so she can verify it and indicate if the key is correct or not, i.e., if the user trusts the server to which a session is being started, or not. For this, the user must be in the possesion of the public key fingerprint of the SSH server to which she wants to connect (she should be given the public key fingerprint when her account was created). To get the fingerprint of the SSH server public key, issue the following command in the server computer, and write the fingerprint value:

    sudo ssh-keygen -l -f /etc/ssh/

In the client computer (M2) eliminate the public keys that you possibly stored from previous SSH connections. For that purpose, use the following command:

rm ~/.ssh/known_hosts

From the client computer, start an SSH session with the server, using the following command, where username is your account name in the server and host is the name or IP address of the computer with the SSH server (M1):

ssh username@host

The user in the client computer will be presented with a message similar to the one shown bellow, asking if the user trusts the identity of the SSH server she is trying to connect to. Compare the presented public key fingerprint with the fingerprint you get in the SSH server. If they are equal, then you are trying to connect to the SSH server you intent to connect and you must answer yes.

The authenticity of host ' (' can't be established.
RSA key fingerprint is 6a:de:e0:af:56:f8:0c:04:11:5b:ef:4d:49:ad:09:23.
Are you sure you want to continue connecting (yes/no)? yes

After the confirmation the client stores the public key in the /̃.ssh/known_hosts file and the user is never again requested to confirm that SSH server public key, as long as the server keeps presenting the same public key.

Proceed to start the SSH session, by introducing your password to authenticate yourself to the SSH server. Login and password is the default mechanism for user authentication with SSH servers.

User authentication with an assymetric key pair

In the client computer you must generate an assymetric key pair to use for client authentication when starting a ssesion in an SSH server. For that, use the following command:

ssh-keygen -t rsa

Press Enter to accept the default name for the file where the key pair will be stored, and define a password for key protection.

Now, you need to install your public key in the SSH server, in order the server can use it to authenticate you when starting SSH sessions. For that purpose, use the following command, where ~/.ssh/ is the default filename used to store client keys (replace it with the name of the file where you stored your key pair, in case you haven’t used the default file name), and username and server are the name of the account and the name of the computer where you want to install your public key:

    ssh-copy-id -i ~/.ssh/ <username>@<server>

This command stores your public key in the ~/.ssh/authorizedkeys file in the home folder of the user account in the server computer. This public key will be used to verify the user possesion of the corresponding private key, whenever the user starts an SSH session with the server.

In the client computer, start a new SSH session to the SSH server in M1. Notice that your public key is used for your authentication and you are not requested to introduce your password.

Compare public key authetication with password authentication when starting an SSH session and analyse the adavantages and disadvantages from one in relation to the other.

Public key authentication on SSH is substancially different from the authentication in SSL protocol. Explain the differences.

Do you think it is adequate to use the SSH public key authentication to authenticate Web servers in the Internet, for example to authenticate Google or Facebook servers? Explain.

User authentication with one-time passwords

Situations may exist where assymetric key pairs might not be the most adequate mechanism to authenticate users when establishing SSH sessions. For example, one such situation may occur when the user uses a shared computer and fears that its key pair can be compromised. In such situations, one-time passwords may be the most adequate mechanism for user authentication when establishing an SSH session with a remote server, since one-time passwords can only be used one single time (they are not reusable), and therefore no security mechanisms are needed to secure its use.

Server configuration

To use one-time passwords in SSH, you need to install OTPW in the server. Use the following command:

sudo apt-get install libpam-otpw otpw-bin

Then you need to configure PAM (Plugable authentication Module) module of SSH. For that, you must edit the /etc/pam.d/sshd configuration file (using vim or gedit, for example). You must disable password authentication, by commenting the following line (by placing a # character in the beginning of the line):

#@include common-auth

Then, you must add the following two lines to enable user authentication using one-time passwords:

auth    required
session optional

Then you must configure the SSH server to accept one-time passwords. For that, you must edit the /etc/ssh/sshd_config file to enable the following three parameters (check that none of these parameters is duplicated, to avoid server faillures when starting):

UsePrivilegeSeparation      yes
ChallengeResponseAuthentication yes
UsePAM  yes

You also need to disable password authentication. However, we will allow public key authentication to prevent the possibility of all one-time passwords were used. For that, edit again the /etc/ssh/sshd_config file and check the following two parameters have the indicated values:

    PubkeyAuthentication    yes
    PasswordAuthentication  no

SSh server configuration is completed, and must be restarted.

One-time passwords generation

One-time passwords for user authentication must be generated and given to the user, in order she can use to authenticate when establishin an SSH session. To generate the user one-time passwords, the user must be logged in the SSH server (not has root) and must execute the following command, where fname.txt is a name for the file to store the generated one-time passwords. When executing the command, the user will be requested to introduce a prefix for the one-time passwords, that the user must memorize because it will be requested, together with the one-time password, when authenticating.

otpw-gen > fname.txt

Look at the contents of the file with the generated one-time passwords. Notive that the one-time passwords are numbered and that each occupies two columns to make them easy to read. When the user is requested to introduce a one-time password for authentication, she must concatenate the text in the two columns, i.e., the blank space between the two columns must not be introduced.

The user must print the file to bring the one-time passwords with her, in order she can use them whenever she establishes a new SSH session with the server.

Using one-time passwords

The establishment of a new SSH session is done with the same command as indicated elsewhere above in this guide, but now, the server will request one of the one-time passwords the user generated. The requested one-time password is identifyed by its number in a format similar to:

Password 123:

The full one-time password to be introduced is composed by two parts: the prefix (defined by the user when she generated the one-time passwords) and the identifyed one-time password that the user must read from the file containing the one-passwords she generated). The user must concatenate the prefix with the requested one-time password. If the correct password is introduced, SSH session is established.


Authored by João Paulo Barraca, André Zúquete, and Hélder Gomes