Changes

OPS235 Lab 7 - CentOS7 - VMware

2 bytes added, 14:28, 25 May 2016

no edit summary

== Part 1: Enabling the sshd service. ==

# Use your '''~~c7host~~centos1''' machine to complete this section

# OpenSSH should have been installed by default. Let's confirm this by issuing the command: <code>rpm -qa | grep ssh</code>

# You should see a number of packages installed including openssh-clients and openssh-server

# Use your '''~~centos2~~centos3''' VM to complete this section.

# Open a terminal and run the '''netstat''' command (pipe to "grep sshd") to check the state of the connection. What is the state (i.e. LISTENING or ESTABLISHED)?

# Open another terminal and establish an ssh connection to your '''~~centos3~~centos4''' VM using the command: <code>ssh ops235@~~centos3~~centos4</code> (Where 'ops235' is the account on ~~centos3~~ centos4 and '~~centos3~~centos4' is the hostname of the ~~centos3~~ centos4 VM.)

# You should receive a message similar to the following:

#::The authenticity of host '~~centos3~~ centos4 (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 '~~centos3~~centos4' (RSA) to the list of known hosts.

# Answer '''yes''' to add to the list of known hosts.

# Issue the following command to confirm that you connected to your ~~centos3~~ centos4 VM: <code>hostname</code>

[[Image:spoof.png|thumb|right|485px|If you receive a message like the one displayed above, 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="7">Switch back to the original terminal and re-run the netstat pipeline command again. Any change to the connection status?</li><li>Return to the second terminal, and logout of your ssh connection by typing <code>exit</code>.

<li>Run the netstat command in the original terminal and check the state of the connection after logging out. Wait a few minutes and then check again. Record your observations.</li>

<li>Make certain to exit all connections, and remain in your '''~~centos2~~centos3''' VM. When using ssh to connect to other servers, it is very easy to forget which server you are currently using. Verify that you are in your '''~~centos2~~centos3''' VM by entering the command: <code>hostname</code>

<li>Use the Internet to search for '''TCP 3 way handshake''' to see how TCP connections are established and closed. </li>

</ol>

::Your public key has been saved in /home/user1/.ssh/id_rsa.pub.

::The key fingerprint is:

::93:58:20:56:72:d7:bd:14:86:9f:42:aa:82:3d:f8:e5 user1@~~centos2~~centos3

<ol><li value="16"> After generating the keys it prompts you for the location to save the keys. The default is '''~/.ssh''' Your private key will be saved as id_rsa and your public key will be saved as '''id_rsa.pub'''</li>

<li>You will then be prompted for a pass-phrase. The pass-phrase must be entered in order to use your private key. Pass-phrases are more secure than passwords and should be lengthy, hard to guess and easy to remember. For example one pass-phrase 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 pass-phrase 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. </li>

<li>Now issue the command <code>ssh-copy-id -i ~/.ssh/id_rsa.pub ops235@~~centos3~~centos4</code></li> <li>Try using ssh to now log into your '''~~centos3~~centos4''' VM from your '''~~centos2~~centos3''' VM. What happens? Were you required to use your pass-phrase? Issue the hostname command to verify that you are successfully logged into your '''~~centos3~~centos4''' VM.</li><li>Make certain to logout of your '''~~centos3~~centos4''' system. Use the '''hostname''' command to verify you are back in your ~~centos2~~ centos3 server.</li>

</ol>

# Remain in your '''~~centos2~~centos3''' VM for this section.# To connect to a remote host type the command: <code>sftp ops235@~~centos3~~centos4</code>

# This will establish an interactive session after authentication.

# Type <code>help</code> to see the list of sftp commands at any time.

|- valign="top"

|{{Admon/tip| SELinux | SELinux may prevent ssh from accessing your home directories on ~~centos1~~ centos2 because you created a new filesystem there. You can reset the security context of the /home directory with this command: '''restorecon -Rv /home'''}}

|}

<ol>

<li value="8">You can also use the '''scp''' command to copy files to and from remote hosts and even from one remote host to another.</li>

<li>Use '''scp''' to copy your services file to the ~~centos3~~ centos4 host into the /tmp directory. (The path on a remote host follows the ''':''') using the command: <code>scp /etc/services ops235@~~centos3~~centos4:/tmp</code></li><li>Here is a neat trick: You can run commands remotely using ssh by typing the command as an argument after the ssh command. Issue the following command in your '''~~centos2~~centos3''' VM: <code>ssh ops235@~~centos3~~ centos4 ls /tmp</code></li><li>What happened when you issued that command? Where you able to successfully using scp to copy the '''/etc/services''' file to '''~~centos3~~centos4's /tmp''' directory?</li><li>Experiment with '''scp''' to copy a file from '''~~centos3~~centos4''' directly to '''~~centos1~~centos2'''.</li>

</ol>

|- valign="top"

|{{Admon/tip | ~~centos1~~ centos2 VM iptables and ssh service | You may need to adjust the firewall on your '''~~centos1~~centos2''' host to complete this section, and verify that the '''sshd''' service is running on that VM.}}

|}

:You can also use ssh to '''tunnel window and bitmap information''', allowing us to login to a remote desktop host and '''run a Xwindows application''' such as gedit or firefox and the application will run on the remote host but be displayed on the local host.

# For this section, you will be using your '''~~centos1~~centos2''' and '''~~centos2~~centos3''' VMs.# From your '''~~centos2~~centos3''' VM issue the ssh command to connect to your '''~~centos1~~centos2''' VM using the following command: <code>ssh -X -C username@~~centos1~~centos2</code>   (where 'username' is your learn account on ~~centos1~~centos2) (The '''-X''' option enables the forwarding of X window information, and the '''-C''' option enables compression for better performance).

# Once the connection is properly established, run the '''gedit''' application. (Gnome Text Editor)

# The ''gedit'' window will display on your '''~~centos2~~centos3''' VM, but in reality, this application is running on your '''~~centos1~~centos2''' VM!

# Enter some text and save a file with '''gedit'''.

# Exit the '''gedit''' application.

# For this section, you will still be using your '''~~centos1~~centos2''' and '''~~centos2~~centos3''' VMs.

# We will be bypassing a firewall that blocks http traffic.

# In this investigation, '''~~centos1~~centos2''' will be your '''http server''' and '''~~centos2~~centos3''' will be your client.# Use the '''hostname''' command to verify that you are in your ~~centos1~~ centos2 VM (as opposed to another VM by mistake via ssh!)

# On the HTTP server, make sure that the Apache web server is installed by typing the command: <code>rpm -q httpd</code>

# If this is not installed, make sure to install '''httpd'''.

# Confirm that httpd is listening to TCP/80 using the '''netstat''' command.

# Create a small html document called '''/var/www/html/index.html''' that displays a short message. If you do not know how to use HTML markup language, just type a simple text message...

# Restart your '''~~centos1~~centos2''' VM. # On your '''~~centos1~~centos2''' VM (i.e. the http server), confirm everything is working locally by using a browser to connect to '''http://localhost'''# Set the default firewall configuration on ~~centos1~~ centos2 to '''REJECT''' incoming requests to http (TCP/80)# NOTE: '''~~centos1~~centos2''': if '''http://localhost''' stops working locally, add the following iptables rule to ~~centos1~~centos2, as root <code>iptables -I INPUT -i lo -j ACCEPT</code> # On '''~~centos2~~centos3''' confirm that the httpd service is stopped so it cannot interfere with your observations.# On '''~~centos2~~centos3''' confirm that you can't connect by using firefox to ~~centos1~~ centos2 '''http://~~centos1~~centos2/'''

# The next step is to establish a tunnel. When you establish a tunnel you make an ssh connection to a remote host and open a new port on the local host. That local host port is then connected to a port on the remote host through the established tunnel. When you send requests to the local port it is forwarded through the tunnel to the remote port.

# In a terminal in your '''~~centos2~~centos3''' VM, '''make certain you are NOT logged in as root!'''# Establish a tunnel using a local port on ~~centos2~~ centos3 of 20808, that connects to the remote port on '''~~centos1~~centos2''' of 80, using the following command on '''~~centos2~~centos3''': <code>ssh -L 20808:~~centos1~~centos2:80 username@~~centos1~~centos2</code> '''Note:''' The '''-L''' option (which means Local port) takes one argument: <local-port>:<connect-to-host>:<connect-to-port> The command basically connects your local port of 20808 to the remote port of 80 on '''~~centos1~~centos2'''. This means all requests to 20808 on the localhost ('''~~centos2~~centos3''') are actually tunnelled through your ssh connection to port 22 on '''~~centos1~~centos2''' and then delivered to port 80 on '''~~centos1~~centos2''', bypassing the firewall. # Once the tunnel is established use '''netstat''' to verify the port 20808 is listening on '''~~centos2~~centos3'''# Now using the browser on '''~~centos2~~centos3''' connect to '''http://localhost:20808'''#You should see the '''index.html''' page on '''~~centos1~~centos2'''.

# Close the ssh connection and verify that the port 20808 is no longer listening.

# For this section, you will still be using your '''~~centos1~~centos2''' and '''~~centos2~~centos3''' VMs.

# Think of a good quality password and change your root passwords on all 3 VM's to be more secure. (It would be a good idea to do this for non-root accounts also)

# The next change you can make is to prevent the root account from logging in to sshd altogether.

# Change to your '''~~centos2~~centos3''' VM and open a terminal.

# Edit the file '''/etc/ssh/sshd_config''' and look for the option '''PermitRootLogin'''. Un-comment the option (or add the option if it does not appear) and change the option value to '''"no"'''. '''NOTE:''' Now any hacking attempt also has to guess an account name as well as the password. If you need to ssh with root access, ssh as a regular user and use '''su -''' to become root.

# Even better, it is possible to restrict access to just specific users that require it.

# Edit the file '''/etc/ssh/sshd_config''' and add a new option of '''"AllowUsers account"''' using your login account for account

# In order for these changes to be effective, issue the following command to restart the sshd service: <code>service sshd restart</code>

# Try sshing from your '''~~centos1~~centos2''' VM to your '''~~centos2~~centos3''' VM. Where you successful? Would it work if you let "AllowUsers account" without a username, or a non-existent username? Do not do this for your machine!

# Next change the default port number that sshd uses (TCP:22).

# Edit the '''/etc/ssh/sshd_config''' file again, un-comment the port option and change the port number it uses from ''22'' to '''2200'''.

# Next, we will drop any incoming traffic to port 22 by issuing the command: <code>iptables -I INPUT -p tcp -s0/0 --dport 22 -j DROP</code>

# We have now possibly mislead a potential "hacker" to the true port for our ssh server's communication channel (port).

# Switch to your '''~~centos1~~centos2''' VM.# Issue the commmand: <code>ssh username@~~centos2~~centos3</code>. What happens? What port do you think that command is using by default?# Now issue the following command to ssh via port "2200": <code>ssh -p 2200 username@~~centos2~~centos3</code>. Where you able to connect?

{|width="40%" align="right"

'''Arrange proof of the following on the screen:'''

<ol><li>✓ '''~~centos2~~centos3''' VM:<blockquote><ul><li>have tunneled Xwindows application from '''~~centos1~~centos2''' via ssh</li><li>have tunneled http through firewall using ssh (on web-browser</li><li>have secured ssh against root access</li></ul></blockquote><li>✓ '''~~centos3~~centos4''' VM:<blockquote><ul><li>have configured sshd to '''allow connection to ~~centos3~~ centos4 VM'''</li><li>have logged in ~~centos3~~ centos4 VM using '''public key authentication'''</li><li>have scp'd and sftp'd files to ~~centos3~~ centos4 VM</li></ul></blockquote></li><li>✓ '''~~c7host~~centos1''' Machine:<blockquote><ul><li>Confirmation that sshd is running on host machine</li></ul></blockquote><li>✓ '''Lab7''' log-book filled out.</li></ol>

Msaul

Administrators

13,420

edits

CDOT Wiki β

Changes

OPS235 Lab 7 - CentOS7 - VMware

CDOT Wiki ^β