Difference between revisions of "SRT210 Lab 8"

From CDOT Wiki
Jump to: navigation, search
(PART 1: HOST FINGERPRINTS)
Line 15: Line 15:
 
* 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.
 
* 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]]
 
* 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]]
 +
* SSH to every one of your nested VMs and save their fingerints and check the contents of your ~/.ssh/known_hosts file to make sure they're there.
 +
* Then create a new user on c7host, switch to that user (in a terminal, using the "su" command), and try to ssh to one of those hosts again. Notice that the new user needs to confirm that fingerprints are correct again. Delete the new user, including their home directory.
  
 
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.
 
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 and check the contents of your ~/.ssh/known_hosts file to make sure they're there.
 
 
* 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.
 
* 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.
 
+
* Create the /etc/skel/.ssh/ directory, and copy your user's ~/.ssh/known_hosts into there.
 +
* Then again create a new user on c7host, switch to that user (in a terminal, using the "su" command), and check that user's ~/.ssh/known_hosts file.
 +
* SSH to one of your hosts to confirm that you don't need to verify that host's fingerprint.
  
 
= PART 2: SSH KEYS =
 
= PART 2: SSH KEYS =

Revision as of 10:56, 2 April 2019

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:
    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.
  • 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:
    Spoof.png
  • SSH to every one of your nested VMs and save their fingerints and check the contents of your ~/.ssh/known_hosts file to make sure they're there.
  • Then create a new user on c7host, switch to that user (in a terminal, using the "su" command), and try to ssh to one of those hosts again. Notice that the new user needs to confirm that fingerprints are correct again. Delete the new user, including their home directory.

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.

  • 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.
  • Create the /etc/skel/.ssh/ directory, and copy your user's ~/.ssh/known_hosts into there.
  • Then again create a new user on c7host, switch to that user (in a terminal, using the "su" command), and check that user's ~/.ssh/known_hosts file.
  • SSH to one of your hosts to confirm that you don't need to verify that host's fingerprint.

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.