CISS-150 Project 8 – Multifactor Authentication (MFA)

CISS-150 Project 8 (10 points)

(Updated April 20, 2023)

This project focuses on making protocols more secure. When a service is forward-facing to the Internet, a username and password are simply not strong enough to keep out the interlopers. In addition to enabling the Secure Shell protocol (SSH), you will implement certificate authentication and OATH-TOTP [Initiative for Open Authentication (OATH) Time-based One Time Password (TOTP)].

Learning outcomes

• Planning and design.
• Enhancing existing virtualization and networking skills.
• VMware guest security.
• Installing updates and application software.
• Implementation of SSH protocol server.
• Multi-Factory authentication concepts.

The username/password is an important part, however, certificate-based authentication helps to restrict where you can connect. The TOTP component changes every 30 seconds and therefore requires an external source.

Installing the necessary software

From the Ubuntu VM, run the following as the root user:

apt update
apt install openssh-server libpam-google-authenticator

We now have the OpenSSH server and Google Authentication components installed. More on these later.

Now, go to the Windows 10 VM. Download & install the PuTTY MSI 64-bit installer from Putty Programs

This client software will be used to generate keys and to test the three factors of authentication that are described below.

First factor of authentication

Create a new user called newuser on Ubuntu:

useradd -m -s /bin/bash newuser
passwd newuser
(when prompted, set the password to newuser)

From Windows 10, use PuTTY to SSH to the Ubuntu VM as newuser using the IP address of the Ubuntu VM and the username you just created. Your transcript should look something like:

login as: newuser
newuser@192.168.1.6's password:
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 updates can be applied immediately.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

newuser@student-vm:~$

Now we’ve confirmed the first form of authentication. But this is simply not that exciting because username/password authentication has been around a very long time.

Disconnect the SSH session.

Second factor of authentication

This is the certificate or key-based access. This involves setting up a predetermined directory structure that will be honored by the SSH daemon running on Ubuntu. Remember that Windows 10 is the client machine wishing to gain access to the Ubuntu server machine. This means we need to generate the key on the client and place the public component on the server.

The directory structure for the server side is similar the following:

/home
   |--> newuser
           |--> .ssh
                  |--> known_hosts
                  |--> authorized_keys
                  |--> id_rsa.pub
                  |--> id_rsa

• The known_hosts file is a list of fingerprints of the servers we have visited. This is used to validate the endpoint in the future. If the fingerprint changes, there is a strong possibility of compromised security.
• The id_rsa and id_rsa.pub files are the private and public keys, respectively, for this user. The user can share out the public key to another host. Why? Because the user has the private key. The user gives the public key to another entity essentially saying, “Hey this is my public key so you know it’s me when I connect.” The server encrypts/signs the data using the public key that only the holder of private key can decrypt. Obviously, the private key should be closely guarded and is usually further secured with a passphrase. (see below)
• The authorized_keys file is used by a server endpoint to indicate who is authorized to access this account via a key. As described above, the shared public key for a user at a client machine is placed in this file. There can be many keys in this file. Essentially, we are authorizing access to this user account by those who possess the private key of any of the matching public keys in this file. Depending on the security imposed in the SSH server configuration file, this key could be optional or required.

Ok, so why all the talk about public and private keys and the authorized_keys file? Well, hopefully you’ve put some of the pieces together and realized this is clever way to restrict access to a user account with an additional, pre-shared, component.

Incidentally, this key/certificate mechanism can be used in a lot of ways:

• To augment the current username/password model by allowing certificate-based (key-based) access as an alternative.
• To augment the current username/password model by mandating certificate-based (key-based) access as a requirement.
• To combine the current username/password model with mandating certificate-based (key-based) access as a requirement.
• To allow passwordless access to a server. WHAT?! Passwordless?! Yup. When carefully implemented, this could be used to allow a script running on one machine to send files to another without the required user intervention of entering that pesky password.

These are the most common forms of implementation and can be combined with other requirements to make your system particularly difficult to enter. But, keep in mind that all of this security only applies to those trying to get in via the SSH protocol. Properly secured systems with firewalls can be made practically impenetrable. This is just one step amidst many that are required for that level of protection.

On the Windows 10 machine, do the steps listed below. Please read through these steps before you begin. This is not something you simply breeze through – it requires active participation to be successful!

• Run the PuTTY Gen key generator.
• Generate a 2048 bit RSA key.
• Enter a passphrase to secure the key. Be sure to actually use the word passphrase as the passphrase.
• Copy the Public key for pasting into OpenSSH authorized_keys file and email it to yourself. There is no copy/paste between VMs, so improvise.



• Save the public and private keys to your desktop (so you can find them later!)

Go back to Ubuntu as your newuser, login to email, get the public key and place the public key into the authorized_keys file. The steps are shown below. Note that there are no spaces before the .ssh.

mkdir /home/newuser/.ssh
chmod 700 /home/newuser/.ssh
gedit /home/newuser/.ssh/authorized_keys

As the root user, edit the /etc/ssh/sshd_config and add the following to the end:

AuthenticationMethods publickey,password publickey,keyboard-interactive

Restart the SSH daemon using:

service ssh restart

This basically says we need a SSH key (publickey), password (password publickey) and verification code (keyboard-interactive). The strongest portion of this is the publickey. If you do not attempt to authenticate from the client that generated the SSH key pair, there is no hope at all of completing the next phase(s) as the connection will be be outright denied.

Now, return to Windows 10, open PuTTY. You MUST do all of the following steps to be successful:

• Type in the IP address of your Ubuntu machine.
• Under Connection, expand SSH and select Auth.
• Select Browse to set your private key and select the one you previously saved on your desktop.

Select Open.
Select Yes to save the fingerprint.
Enter your newuser.

Your transcript should look something like:

login as: newuser
Authenticating with public key "rsa-key-20201019"
Passphrase for key "rsa-key-20201019":
Further authentication required
newuser@192.168.1.6's password:
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 updates can be applied immediately.

Last login: Tue Nov 22 10:40:34 2022 from 192.168.1.6
newuser@student-vm:~$

Phew! We’ve completed two factors!

Third factor of authentication.

Login as your newuser, either via SSH or the console. You will need to run the following command as that user. This will setup the Google authenticator component.

google-authenticator

Use the following responses:

Time based tokens   = Y
Update the file     = Y
Disallow multiple   = Y
Increase the window = N
Rate limiting       = Y

NOTE: You can download the Google Authenticator app for your smartphone OR you can simply use the emergency scratch codes that are provided in the setup. Either way is fine, but it’s more exciting to try out the app.

As the root user edit the /etc/pam.d/sshd file and add the following line to the end:

auth optional pam_google_authenticator.so nullok

The optional option can be made required once you know for sure the google-authenticator portion is working as expected.

Finally, edit the /etc/ssh/sshd_config file again and change the following line:

KbdInteractiveAuthentication yes

This allows for the SSH daemon to know about and use the pam_google_authenticator module.

Restart the SSH daemon using:

service ssh restart

Testing

Again, login to you newuser account from the Windows 10 VM. You will still need to use the certificate, but now you will also be given the opportunity to provide a code issued from Google Authenticator or an emergency scratch code. Since this is also optional (at the moment) you can simply hit enter when prompted for the verification code. Your outpu should look something like the following:

login as: newuser
Authenticating with public key "rsa-key-20201019"
Passphrase for key "rsa-key-20201019":
Further authentication required
Using keyboard-interactive authentication.
Password:
Using keyboard-interactive authentication.
Verification code:
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 updates can be applied immediately.

Last login: Tue Nov 22 10:40:34 2022 from 192.168.1.6
newuser@student-vm:~$