SSH Hardening Guide

SSH Hardening Guide

This guide provides essential steps to secure your Secure Shell (SSH) server, reducing the risk of unauthorized access and brute-force attacks. We will cover key-based authentication, disabling root login, changing the default SSH port, and implementing Fail2ban for automated intrusion prevention.

Prerequisites

Before you begin, ensure you have:

• Access to your server via SSH with root or sudo privileges.
• A basic understanding of the Linux command line.
• A text editor like `nano` or `vim` installed.
• A stable internet connection.

1. Key-Based Authentication

Key-based authentication is more secure than password-based authentication as it relies on cryptographic keys.

Generate SSH Keys

On your local machine (not the server), generate an SSH key pair:

ssh-keygen -t rsa -b 4096

This will create two files: `id_rsa` (your private key) and `id_rsa.pub` (your public key). Keep your private key secret and do not share it.

Copy Public Key to Server

Use the `ssh-copy-id` command to securely copy your public key to the server:

ssh-copy-id user@your_server_ip

Replace `user` with your username on the server and `your_server_ip` with the server's IP address. You will be prompted for your password.

If `ssh-copy-id` is not available, you can manually copy the content of `~/.ssh/id_rsa.pub` on your local machine and append it to `~/.ssh/authorized_keys` on the server. Ensure the `~/.ssh` directory and `authorized_keys` file have the correct permissions:

# On the server
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys << EOF
# Paste your public key content here
EOF
chmod 600 ~/.ssh/authorized_keys

Test Key-Based Authentication

Log out of your current SSH session and try logging in again:

ssh user@your_server_ip

You should now be able to log in without a password.

2. Disable Root Login

Directly logging in as root is a security risk. It's better to log in as a regular user and then use `sudo` for administrative tasks.

Edit SSH Configuration

Open the SSH daemon configuration file:

sudo nano /etc/ssh/sshd_config

Find the line `#PermitRootLogin yes` (or similar) and change it to:

PermitRootLogin no

If the line is commented out with a `#`, remove the `#`.

Restart SSH Service

Apply the changes by restarting the SSH service:

sudo systemctl restart sshd

or on older systems:

sudo service ssh restart

Test Root Login

Try to log in as root from your local machine:

ssh root@your_server_ip

This login should be denied. Ensure you can still log in as your regular user.

3. Change Default SSH Port

The default SSH port (22) is a common target for automated attacks. Changing it to a non-standard port can significantly reduce the noise in your logs.

Edit SSH Configuration

Open the SSH daemon configuration file again:

sudo nano /etc/ssh/sshd_config

Find the line `#Port 22` and change it to your desired port (e.g., 2222):

Port 2222

Choose a port between 1024 and 65535 that is not already in use.

Update Firewall (if applicable)

If you are using a firewall (like `ufw` or `firewalld`), you need to allow traffic on the new port.

For UFW:

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo ufw reload

For firewalld:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload

Restart SSH Service

Restart the SSH service for the port change to take effect:

sudo systemctl restart sshd

or on older systems:

sudo service ssh restart

Test New SSH Port

Log out and try connecting to your server using the new port:

ssh user@your_server_ip -p 2222

If you are using a cloud provider like PowerVPS (https://powervps.net/?from=32) or Immers Cloud GPU (https://en.immers.cloud/signup/r/20241007-8310688-334/), ensure that the new port is allowed in your cloud provider's firewall settings as well.

4. Install and Configure Fail2ban

Fail2ban is an intrusion prevention software that scans log files and bans IP addresses that show malicious signs – too many password failures, seeking exploits, etc.

Install Fail2ban

# For Debian/Ubuntu
sudo apt update
sudo apt install fail2ban
# For CentOS/RHEL
sudo yum install epel-release
sudo yum install fail2ban

Configure Fail2ban

Fail2ban's configuration is in `/etc/fail2ban/jail.conf`. However, it's best practice to create a local configuration file to override defaults and prevent your changes from being overwritten during package updates.

Create a local configuration file:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit the `jail.local` file:

sudo nano /etc/fail2ban/jail.local

Ensure the following settings are configured. You can find the `[sshd]` section and modify it.

• bantime: The duration for which an IP address is banned.

    bantime = 1h
    

• findtime: The time window during which failed attempts are counted.

    findtime = 10m
    

• maxretry: The number of failed attempts before an IP is banned.

    maxretry = 5
    

• ignoreip: A list of IP addresses that should never be banned (e.g., your home IP).

    ignoreip = 127.0.0.1/8 your_home_ip_address
    

Make sure the `[sshd]` section is enabled and configured correctly. If you changed your SSH port, update the `port` directive:

[sshd]
enabled = true
port = 2222  ; Use your custom SSH port here
filter = sshd
logpath = /var/log/auth.log ; Or /var/log/secure on CentOS/RHEL
maxretry = 5
bantime = 1h
findtime = 10m

Start and Enable Fail2ban

Start the Fail2ban service and enable it to start on boot:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Monitor Fail2ban

You can check the status of Fail2ban and see which IPs are banned:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Troubleshooting

• Cannot connect after changing port:
* Did you restart the SSH service? * Did you update your firewall rules (server and cloud provider)? * Did you specify the new port when connecting (`ssh -p 2222 user@your_server_ip`)?
• Cannot log in with SSH keys:
* Is your public key correctly added to `~/.ssh/authorized_keys` on the server? * Are the permissions on `~/.ssh` (700) and `~/.ssh/authorized_keys` (600) correct on the server? * Is `PubkeyAuthentication yes` set in `/etc/ssh/sshd_config`?
• Fail2ban is not banning IPs:

Conclusion

By implementing these SSH hardening measures, you significantly enhance the security posture of your server. Remember to regularly review your server's security logs and keep your system updated. For demanding workloads, consider powerful GPU servers available at Immers Cloud.

Category:Security Category:Server Administration Category:Linux