Welcome to my latest blog post on my RH124 journey! In Chapter 10, I had the opportunity to delve into the world of SSH (Secure Shell) and learn how to configure and secure it for remote system access. As we all know, SSH is an essential tool for managing remote servers securely, and in this lab, I had the chance to set up key-based authentication for users, and disable direct login as root and password authentication for the OpenSSH service on one of my servers. In today's increasingly connected world, it's crucial to understand how to configure SSH to ensure that our systems are protected from unauthorized access. In this lab, I went through a series of tasks that allowed me to set up key-based authentication, a more secure method of logging in to remote systems without the need for passwords. I also explored how to disable direct logins as root and password-based authentication, which are common security best practices in the industry. By the end of this lab, I gained valuable knowledge on how to configure and secure SSH, which will enable me to manage my servers in a more secure and efficient manner. So, let's dive into my experience and learn how I enhanced the security of my remote system access with SSH!

Question 1: From the workstation machine, log in to the servera machine as the student user.

Solution:

For Task 1, I logged in to the servera machine as the student user from my workstation machine using the following command: ssh student@servera. This allowed me to establish a secure SSH connection to the servera machine as the student user and gain remote access for further configuration. SSH provides a secure and encrypted means of connecting to remote systems, ensuring that login credentials and data are protected during transit.

Question 2: Switch to the production1 user on the servera machine. Enter redhat as the password.

Solution:

To switch to the production1 user on the servera machine and enter the password "redhat", I used the su - production1 command.

The su command stands for "switch user" and allows me to switch to a different user account on the servera machine. The **-** option ensures that the environment variables and settings of the new user, in this case, production1, are loaded properly. After entering the correct password "redhat", I was able to switch to the production1 user and work within that user's environment for further configuration tasks.

Question 3: Generate passphrase-less SSH keys for the production1 user on the servera machine.

Solution:

I generated passphrase-less SSH keys for the production1 user on the servera machine using the ssh-keygen command. This command prompts for a passphrase, but to generate a passphrase-less key, I simply pressed the Enter key twice, leaving the passphrase empty. The ssh-keygen command is a powerful tool that generates public and private key pairs for SSH authentication. The passphrase provides an additional layer of security to protect the private key, but using a passphrase-less key means that no passphrase is required when using the key for authentication, making it more convenient for automated processes or scripts. However, it's important to note that passphrase-less keys should be used with caution and only in secure environments, as they may pose a security risk if not properly protected.

Question 4: Send the public key of the SSH key pair to the production1 user on the serverb machine.

Solution:

I sent the public key of the SSH key pair to the production1 user on the serverb machine using the ssh-copy-id prodiction1@serverb command. This command copies the public key generated in the previous step to the serverb machine, and adds it to the authorized keys of the production1 user. This allows the production1 user to log in to the serverb machine securely using the SSH key pair, without needing to enter a password. The ssh-copy-id command is a convenient way to set up key-based authentication between remote systems, improving security and eliminating the need for passwords during SSH logins.

Question 5: Verify that the production1 user can successfully log in to the serverb machine with the SSH keys.

Solution:

I verified that the production1 user can successfully log in to the serverb machine with the SSH keys using the command ssh production1@serverb After setting up the key-based authentication in the previous tasks, I was able to use the SSH keys to securely log in to the serverb machine as the production1 user without needing to enter a password. This confirms that the key-based authentication is working correctly and allows for secure and convenient remote access to the serverb machine.

Question 6: Configure the sshd service on serverb to prevent users from logging in as the root user. Use redhat as the root password.

Solution:

I configured the sshd service on serverb to prevent users from logging in as the root user. Here are the steps I followed:

1. Opened the sshd configuration file /etc/ssh/sshd_config **on serverb using a text editor, such as vim.
2. Searched for the option 'PermitRootLogin' in the sshd_config file.
3. Changed the value from 'yes' to 'no' to prevent root login via SSH.
4. Saved and closed the sshd_config file.
5. Reload the sshd service using systemctl reload sshd.
6. Opened a new terminal and logged in to servera as the production1 user using the ssh production1@servera command.
7. Attempted to log in to serverb as root using the ssh root@serverb command, but received an error message indicating that root login is now disabled.

By disabling root login via SSH, I have improved the security of the serverb machine by preventing direct login as the root user, which is a common security best practice. This helps to protect against unauthorized access and potential security breaches.

Question 7: Configure the sshd service on the serverb machine to allow users to authenticate with SSH keys only, rather than with their passwords.

Solution:

I configured the sshd service on the serverb machine to allow authentication with SSH keys only, rather than with passwords. Here are the steps I followed:

1. Opened the sshd configuration file /etc/ssh/sshd_config on serverb using a text editor.
2. Located the 'PasswordAuthentication' option in the sshd_config file.
3. Changed the value from 'yes' to 'no' to disable password authentication.
4. Saved and closed the sshd_config file.
5. Reloaded the sshd service using the systemctl reload sshd command to apply the changes.
6. Attempted to log in to serverb as the production2 user using the ssh production2@serverb command.
7. Access was denied, confirming that password-based authentication is now disabled and only SSH keys are allowed for authentication.

By disabling password authentication and allowing only SSH key-based authentication, I have enhanced the security of the serverb machine, as SSH keys are considered more secure and less susceptible to brute force attacks compared to passwords. This helps to protect against unauthorized access and strengthens the overall security posture of the system.

Conclusion

Configuring and securing SSH is an important aspect of server administration to ensure secure remote access to systems. In this end-of-chapter lab, we learned how to set up key-based authentication for users, disable direct logins as root, and password-based authentication for the OpenSSH service on a server. By following the steps outlined in the lab, we were able to enhance the security of our system by utilizing SSH keys for authentication and disabling less secure authentication methods. As always, it's essential to prioritize security best practices to safeguard sensitive systems and data. What are your thoughts on securing SSH? Have you implemented similar measures in your own systems? Let us know in the comments below. Your input and feedback are valuable as we continue to explore and share best practices for securing Linux systems.