0% found this document useful (0 votes)
18 views13 pages

Srping2024 Osp201 Lab4

Uploaded by

tu03xly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views13 pages

Srping2024 Osp201 Lab4

Uploaded by

tu03xly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

6.

1 – Creating and transferring SSH keys


1. On the client machine, create a pair of 384-bit elliptic curve keys. Accept the
default filename and location and
create a passphrase:
ssh-keygen -t ecdsa -b 384

2. Observe the keys, taking note of the permissions settings:


ls -l ./ssh

3. Add your private key to your session keyring. Enter your passphrase when
prompted:
exec /usr/bin/ssh-agent $SHELL
ssh-add

4. Transfer the public key to the server VM. When prompted, enter the password
for your user account on the server
VM. (Substitute your own username and IP address in the following command.):
ssh-copy-id donnie@192.168.0.7

5. Log in to the server VM as you normally would:


ssh donnie@192.168.0.7

6. Observe the authorized_keys file that was created on the server VM:
ls -l .ssh
cat .ssh/authorized_keys

Security Strategies in Linux Platforms and Applications – Lab manual


7. Log out of the server VM and close the terminal window on the client. Open
another terminal window and try to
log in to the server again. This time, you should be prompted to enter the
passphrase for your private key.
8. Log back out of the server VM and add your private key back to the session
keyring of your client. Enter the
passphrase for your private key when prompted:
exec /usr/bin/ssh-agent $SHELL
ssh-add
9. As long as you keep this terminal window open on your client, you’ll be able to
log in to the server VM as many
times as you want without having to enter a password. However, when you close
the terminal window, your private
key will be removed from your session keyring.
10. Keep your server VM, because we’ll do more with it in a bit.
You’ve reached the end of the lab – congratulations!

6.2 – Disabling root login and password authentication

1. On either an Ubuntu, CentOS, or AlmaLinux 8 server VM, look for this line in
the sshd_config file:
#PasswordAuthentication yes

2. Remove the comment symbol, change the parameter value to no , and reload the
SSH daemon. The line should
now look like this:
PasswordAuthentication no

3. Now, when the botnets scan your system, they’ll see that doing a brute-force
password attack would be useless.
They’ll then just go away and leave you alone.
4. Look for either of these two lines, depending on whether the server is an Ubuntu
or a CentOS 7/AlmaLinux VM:
#PermitRootLogin yes

#PermitRootLogin prohibit-password
Uncomment the line and change it to the following:
PermitRootLogin no

6. On CentOS/AlmaLinux, do this:
sudo systemctl reload sshd
7. Attempt to log in to the server VM from the client that you used in the previous
lab.

8. Attempt to log in to the server VM from another client on which you haven’t
created a key pair.
(You shouldn’t be able to.)
9. As before, keep the server VM, because we’ll do more with it in a bit.
You’ve reached the end of the lab – congratulations!

6.9 – Configuring more verbose SSH logging


1. Open the main log file and scroll down to where you see the entry that was made
due to your login and observe
what it says. For Ubuntu, do:
sudo less /var/log/auth.log
2. For CentOS or AlmaLinux, do:
sudo less /var/log/secure
3. As I mentioned previously, you never want to run a production machine with the
SSH log level set to any of the
DEBUG levels. But, just so you can see what it does log, set your machine to
DEBUG now. Open the /etc/ssh/sshd_config file in your favorite text editor. Find
the line that says the following:
#LogLevel INFO

4. Change it to the following:


LogLevel DEBUG3

6. On CentOS or AlmaLinux, do this:


sudo systemctl reload sshd

7. Log out of the SSH session, and then log back in. View the system log file to see
the new entries from this new login.
8. Open the /etc/ssh/sshd_config file for editing. Change the LogLevel DEBUG3
line to the following:
LogLevel VERBOSE
9. After saving the file, reload or restart the SSH daemon. Log out of the SSH
session, log back in, and look at the entries in the system log file.

6.10 – Configuring whitelists within sshd_config

This lab will work on any of your VMs. Follow these steps:
1. On the VM that you wish to configure, create user accounts for Frank, Charlie,
and Maggie.
2. On CentOS or AlmaLinux, do it like this:
sudo useradd frank
sudo passwd frank

3. Create the webadmins group and add Frank to it:


sudo groupadd webadmins
sudo usermod -a -G webadmins frank

4. From either your host machine or from another VM, have the three users log in.
Then, log them back out.
5. Open the /etc/ssh/sshd_config file in your favorite text editor. At the bottom of
the file, add an AllowUsers line with
your own username, like so:
AllowUsers donnie

6. Then, restart or reload the SSH service and verify that it has started correctly:

Security Strategies in Linux Platforms and Applications – Lab manual


For CentOS:
sudo systemctl restart sshd
sudo systemctl status sshd

7. Repeat step 3. This time, these three kitties shouldn’t be able to log in. Open
the /etc/ssh/sshd_config file in your
text editor. This time, add an AllowGroups line to the bottom of the file for the
webadmins group, like so:
AllowGroups webadmins

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy