• Courses
    • Oracle
    • Red Hat
    • IBM
    • ITIL
    • PRINCE2
    • Six Sigma
    • Microsoft
    • TOGAF
    • Agile
    • Linux
    • All Brands
  • Services
    • Vendor Managed Learning
    • Onsite Training
    • Training Subscription
  • Managed Learning
  • About Us
    • Contact Us
    • Our Team
    • FAQ
  • Enquire

OUR BLOG


Linux OpenSSH Security Hardening Guide

Posted by Marbenz Antonio on May 11, 2022

14 SSH Key Management Best Practices You Need to Know - Hashed Out by The SSL Store™

On Linux platforms, SSH is one of the most extensively used protocols for system management. It’s compatible with a variety of Unix, Linux, and MacOS-based operating systems. It is based on the client-server concept, in which one computer executes the server component while the other accesses it using a client tool.

How does SSH work?

The connection is established by the user (ssh) submitting a request to the server. The server uses the server daemon to listen for incoming requests (sshd). It authenticates itself to the client attempting to connect to it by using its public key:

This ensures that the client is connected to the correct SSH server. After then, the client can connect to the server. To connect to the server on a Windows client, you’ll need to utilize tools like putty. Both the client and server tools may be installed on the same system, which means you can use the client tool to connect to other computers or your system can act as a server that others can connect to. The config file is stored in the same directory as the other files, but with a slightly different name. The ssh client config file is called ‘ssh config’, whereas the server’s config file is called ‘sshd config’:

No description available.

If you have both files on your machine, you should decide which one you need to configure first. In most situations, it is the server that requires security configuration because it is the gateway to the system.

We’ll start by verifying the status of our server’s SSH daemon, or sshd. We can detect if it’s running and allow it to start automatically when the computer boots up. The command following will check the status of sshd:

$ systemctl status ssh.service

Or use the below one:

$ systemctl status sshd.service

No description available.

If you have both files on your machine, you should decide which one you need to configure first. In most situations, it is the server that requires security configuration because it is the gateway to the system.

We’ll start by verifying the status of our server’s SSH daemon, or sshd. We can detect if it’s running and allow it to start automatically when the computer boots up. The command following will check the status of sshd:

Configuring SSH using the Best Practices

And believe it is now time to begin setting the SSH server setup. We should make a backup of the SSH config file with the default settings before we get our hands dirty with it:

$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp

After performing the backup, we may be comfortable that if we make a mistake with the main file and break SSH, we can restore normality using the backup file.

1. Changing the default fort

By default, the sshd daemon listens on the server’s port 22. It is advised that this value be changed to anything else in order to limit the reach of automated script attacks. This strategy is known as security by obscurity. To do so, open the code below and search for the line that says ‘#Port 22.’

$ sudo nano /etc/ssh/sshd_config

Uncomment the line ‘#Port 22′ and replace ’22’ with a port number that is not already in use on your system. We had to modify the password to ‘222’ and restart the service. To provide the new port, use the ssh command with the option ‘p’:

$ ssh user@system_ip -p 222

No description available.

2. Disabling login as the root user

The root is the most powerful user on a Linux system, with access to all of the system’s resources. You should disable the root login feature on your server if you do not require tight root access. To do so, open the same file as before:

$ sudo nano /etc/ssh/sshd_config

Set the option ‘PermitRootLogin’ to ‘no’. This will guarantee that the server is safe against random assaults aimed at the root account. The default option is ‘prohibit-password,’ which allows for public-key authentication but not password authentication.

3. Setting the protocol version

SSH1 is the earlier protocol version, and it is less secure than SSH2. They also have distinct networking implementations and are incompatible with one another. Open the sshd config file again and search for the line ‘Protocol’: to see which protocol version is active on your server.

$ cat /etc/ssh/sshd_config | grep 'Protocol'

If you get an empty output, OpenSSH is most likely using version 2, as it was in our instance. Another option is to use the Netcat command:

$ nc localhost 22

Sample output:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4

SSH2 is operational on our machine, as seen by the output.

Try connecting to a remote server using an ssh client with the -Q (query) option to see which protocols version it is running:

$ ssh -Q protocol-version user@server_name

No description available.

The screenshot above depicts an SSH version 2 connection from Kali Linux to an Ubuntu ssh server.

4. Password complexity

Empty passwords are more likely to be abused since weak passwords are always open to being exploited. As a result, the PermitEmptyPasswords option in the sshd config file should be set to ‘no’. Similarly, to lessen the probability of a brute force assault, the number of login attempts with incorrect passwords should be reduced. This may be accomplished by setting the ‘MaxAuthTries’ option to a lower number, such as 3.

No description available.

When we set the ‘MaxAuthTries’ setting to 3, we are refused SSH after three incorrect passwords, as shown in the image above. Using public key authentication for login is another important security feature. Brute force assaults are less resistant to key-based authentication methods. Similarly, we may utilize the PAM authentication module to strengthen the SSH server even further.

Conclusion

We’ve tried to cover the most critical aspects of protecting an SSH server in this article and condense them into four primary points. Although this article is not exhaustive, you can find more ways to enhance your SSH server. You might, for example, deploy a banner message to warn users about utilizing SSH to access your system. You can also disable password-based authentication and use key-based authentication instead. Another feature worth mentioning is the ability to limit the number of SSH users as well as their connection time.

 


Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com

Archives

  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • March 2020
  • December 1969

Categories

  • Agile
  • APMG
  • Business
  • Change Management
  • Cisco
  • Citrix
  • Cloud Software
  • Collaborizza
  • Cybersecurity
  • Development
  • DevOps
  • Generic
  • IBM
  • ITIL 4
  • JavaScript
  • Lean Six Sigma
    • Lean
  • Linux
  • Microsoft
  • Online Training
  • Oracle
  • Partnerships
  • Phyton
  • PRINCE2
  • Professional IT Development
  • Project Management
  • Red Hat
  • SAFe
  • Salesforce
  • SAP
  • Scrum
  • Selenium
  • SIP
  • Six Sigma
  • Tableau
  • Technology
  • TOGAF
  • Training Programmes
  • Uncategorized
  • VMware
  • Zero Trust

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

home courses services managed learning about us enquire corporate responsibility privacy disclaimer

Our Clients

Our clients have included prestigious national organisations such as Oxford University Press, multi-national private corporations such as JP Morgan and HSBC, as well as public sector institutions such as the Department of Defence and the Department of Health.

Client Logo
Client Logo
Client Logo
Client Logo
Client Logo
Client Logo
Client Logo
Client Logo
  • Level 14, 380 St Kilda Road, St Kilda, Melbourne, Victoria Australia 3004
  • Level 4, 45 Queen Street, Auckland, 1010, New Zealand
  • International House. 142 Cromwell Road, London SW7 4EF. United Kingdom
  • Rooms 1318-20 Hollywood Plaza. 610 Nathan Road. Mongkok Kowloon, Hong Kong
  • © 2020 CourseMonster®
Log In Register Reset your possword
Lost Password?
Already have an account? Log In
Please enter your username or email address. You will receive a link to create a new password via email.
If you do not receive this email, please check your spam folder or contact us for assistance.