13,420
edits
Changes
no edit summary
{{Admon/note | | If you receive a message like this you should investigate why it is happening as it could indicate a serious security issue, or it could just mean that something on the host has changed, i.e. the OS was reinstalled.}}
<ol><li value="5">* When prompted enter your password for your ops235 account on fedora3.</li>
<li>Establish an ssh connection using your learn account from fedora3 to fedora2.</li></ol>
{{Admon/note | | When you have both ssh connections established between fedora2 and fedora3 check your network connections using the netstat command. You should now see at least 2 TCP connections with a state of ESTABLISHED. One connection represents the connection from fedora2 to fedora3 and the other represents the connection from fedora3 to fedora2. You should also see that you still have ssh listening to TCP port 22. Notice that the client side of each connection uses a random port number in the upper ranges. This common behaviour for client side applications.}}
<ol><li value="7">* Logout of your ssh connection by typing <code>exit</code>.
<li>Check the state of the connection after logging out. Wait a few minutes and then check again. Record your observations.</li>
<li>Use the Internet to search for "TCP 3 way handshake" to see how TCP connections are established and closed.</li></ol>
{{Admon/tip | Tip: | In this part of the lab you established an ssh connection to another host using a password to establish your identity. But passwords are not the only or even the best way of authenticating your identity. We can also use Public/Private key encryption.}}
<ol><li value="10">* Answer the Investigation 2 question in your lab log book.</li></ol>
=== Investigation 3: How do you establish an ssh connection using Public Key Authentication. ===
{{Admon/tip | Tip: | You will then be prompted for a passphrase. The passphrase must be entered in order to use your private key. Passphrases are more secure than passwords and should be lengthy, hard to guess and easy to remember. For example one passphrase that meets this criteria might be "seneca students like fish at 4:00am". Avoid famous phrases such as "to be or not to be" as they are easy to guess. It is possible to leave the passphrase blank but this is dangerous. It means that if a hacker were able to get into your account they could then use your private key to access other systems you use.}}
<ol><li value="4"> Once your keys have been saved you should check to make sure the permissions of the <code>.ssh</code> directory and your key files are secure. </li>
<li> Use the following commands to secure them:<br />** <code>chmod 700 ~/.ssh</code><br />** <code>chmod 600 ~/.ssh/id_dsa*</code><br /></li>
<li>The next step is to copy your public key to fedora3 (the remote host). You can use the scp command to do it.</li>
<li><code>scp</code> (secure copy) is used to copy files between hosts over the ssh protocol. The files are sent over an encrypted channel as is all ssh traffic. </li>
<li>Now ssh to fedora3 using a password to authenticate.</li>
<li>Once logged in to fedora3 we need to add the public key to your list of authorized_keys</li>
<li>he safest way to do this is to append the contents of <code>id_dsa.pub</code> to the <code>.ssh/authorized_keys</code> file. To do this use the command:<br />** <code>cat ~/id_dsa.pub >> ~/.ssh/authorized_keys</code></li></ol>
{{Admon/important | Note! | You don't want to overwrite the file as it may contain multiple public keys. Make sure you are using the append redirection '''>>''' and not '''>'''.}}
<ol><li value="16"> Once again you should secure the <code>.ssh</code> directory and the <code>authorized_keys</code> file using the following commands:<br />** <code>chmod 700 ~/.ssh</code><br />** <code>chmod 600 ~/.ssh/authorized_keys</code></li>
<li>Logout of fedora3 and log back in again.</li>
<li>You should be prompted to enter your passphrase to unlock your private key.</li></ol>
