Changes

Jump to: navigation, search

SRT210 Lab 8

2,454 bytes added, 09:36, 2 April 2019
Created page with "= Objectives = * Semi-automated host fingerprint distribution using /etc/skel. * Use assymetric encryption (with SSH keys) for password-less SSH authentication. * Ditribute S..."
= Objectives =

* Semi-automated host fingerprint distribution using /etc/skel.
* Use assymetric encryption (with SSH keys) for password-less SSH authentication.
* Ditribute SSH public keys manually.

= PART 1: HOST FINGERPRINTS =

* Before you start work on this section, delete all the files in your c7host's ~/.ssh directory.
* Now ssh to root@lin1.yoursenecaid.ops. You should get a prompt like this:<source>The authenticity of host 'centos3 (192.168.235.13)' can't be established.
RSA key fingerprint is 53:b4:ad:c8:51:17:99:4b:c9:08:ac:c1:b6:05:71:9b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'lin1.yoursenecaid.ops' (RSA) to the list of known hosts.
</source>
* That fingerprint is a hash of lin1's public key. You get a warning because SSH doesn't use certificate authorities, therefore there's no way for your SSH client to know whether it's connecting securely to the real lin1 or a man-in-the-middle attacker.
* When you anwer "yes" above, the fingerprint of the key will be stored in your user's ~/.ssh/known_hosts file, and from that point on your SSH client will be confident that it's connecting to the correct host, unless the keys on the destination host change, in which case you'll get a warning like this:<br />[[File:Spoof.png]]

The security of your encrypted SSH tunnels therefore relies on making sure that you have the fingerprints of the hosts you're connecting to. We'll use a simple way to make distributing these fingerprints a little bit easier for all the new users on a system.

* Now ssh to every one of your nested VMs and save their fingerints.
* On your c7host have a look at the /etc/skel directory. It will contain all the files that are inserted into a new user's home directory when it is being created. You can add any other files and directories you like into there.


= PART 2: SSH KEYS =

In the last lab we looked at how we can use public key encryption to secure network traffic from many kinds of attacks. SSH traffic is always encrypted, but this week we will:

* Look more closely at how that works.
* Set up password-less authentication using the same assymetric encryption concepts.

= PART 3: SSH KEY DISTRIBUTION =



= Lab completion =

* Make sure you understand what you've done in this lab, so that you're ready to answer questions about it.
* Have notes in your labbook from this lab.
* Show your work to the professor and have them sign your labbook.

Navigation menu