DEV Community

Big Mazzy
Big Mazzy

Posted on • Originally published at serverrental.store

Setting Up SSH Keys and Hardening SSH Access

#linux #devops #beginners #tutorial

Let's get your server access locked down tight and a bit more convenient. This guide will walk you through setting up SSH keys for secure logins and then hardening your SSH server to fend off unwanted guests.

Why SSH Keys?

When you connect to a server using SSH (Secure Shell), you typically use a username and password. This is like using a key and a lock, but the key is something you have to remember and type, and it can be guessed or intercepted. SSH keys offer a more secure and convenient alternative.

Instead of a password, you use a pair of cryptographic keys: a private key and a public key. Think of your private key as your physical house key – you keep it safe and secret. Your public key is like a special lock you put on your door that only your specific house key can open.

When you try to log in, your computer uses your private key to prove it's you, and the server checks if it matches the public key it has on record. This process is much harder to break than guessing a password. It also means you don't have to type your password every time you connect.

Generating Your SSH Key Pair

The first step is to create your unique SSH key pair. Most systems have the ssh-keygen command built-in. Open your terminal and run the following command:

ssh-keygen -t ed25519 -C "your_email@example.com"
Enter fullscreen mode Exit fullscreen mode

Here's what's happening:

  • ssh-keygen: This is the command to generate SSH keys.
  • -t ed25519: This specifies the type of encryption. Ed25519 is a modern, secure, and fast algorithm.
  • -C "your_email@example.com": This adds a comment to your public key, which is helpful for identifying it later, especially if you manage keys for multiple servers or users. Replace "your_email@example.com" with your actual email address.

The command will then prompt you for a few things:

  1. Enter a file in which to save the key: Press Enter to accept the default location (usually ~/.ssh/id_ed25519). If you already have a key, you might want to specify a different name to avoid overwriting it.
  2. Enter passphrase (empty for no passphrase): This is crucial. A passphrase acts like a password for your private key. Even if someone gets your private key file, they can't use it without the passphrase. It's highly recommended to use a strong passphrase. You'll be asked to enter it twice.

After this, you'll see output indicating that your public and private key files have been created. Your private key (e.g., id_ed25519) should be kept secret. Your public key (e.g., id_ed25519.pub) is what you'll copy to your servers.

Copying Your Public Key to the Server

Now that you have your key pair, you need to place your public key on the server you want to access. This tells the server to trust connections authenticated by your corresponding private key.

The easiest way to do this is using the ssh-copy-id command:

ssh-copy-id username@your_server_ip
Enter fullscreen mode Exit fullscreen mode

Replace username with your username on the server and your_server_ip with the server's IP address or hostname.

When you run this command, it will ask for your server's password. After you enter it, ssh-copy-id will automatically append your public key to the ~/.ssh/authorized_keys file on the server. This file lists all the public keys that are allowed to log in without a password.

If ssh-copy-id isn't available, you can do it manually. First, copy the content of your public key file:

cat ~/.ssh/id_ed25519.pub
Enter fullscreen mode Exit fullscreen mode

Then, SSH into your server using your password, and create the ~/.ssh directory if it doesn't exist, and then create or append to the authorized_keys file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode

Make sure to replace "PASTE_YOUR_PUBLIC_KEY_HERE" with the actual content of your id_ed25519.pub file. The chmod commands set the correct file permissions, which are essential for SSH security.

Testing Your Key-Based Login

After copying your public key, try logging into your server again:

ssh username@your_server_ip
Enter fullscreen mode Exit fullscreen mode

If everything is set up correctly, you should be logged in without being prompted for a password. If you set a passphrase for your private key, you will be prompted for that passphrase.

Disabling Password Authentication

Once you've confirmed that key-based login works, the next critical step is to disable password authentication entirely. This significantly reduces the risk of brute-force attacks.

To do this, you need to edit the SSH server configuration file, typically located at /etc/ssh/sshd_config. You'll need root privileges to edit this file.

sudo nano /etc/ssh/sshd_config
Enter fullscreen mode Exit fullscreen mode

Find the line that says PasswordAuthentication yes and change it to:

PasswordAuthentication no
Enter fullscreen mode Exit fullscreen mode

If the line is commented out (starts with #), uncomment it by removing the # and then change yes to no.

After saving the file, you must restart the SSH service for the changes to take effect. The command varies slightly depending on your Linux distribution:

For systems using systemd (like Ubuntu 15.04+, Debian 8+, CentOS 7+):

sudo systemctl restart sshd
Enter fullscreen mode Exit fullscreen mode

For older systems using SysVinit:

sudo service ssh restart
Enter fullscreen mode Exit fullscreen mode

Important: Before you disable password authentication, ensure you have successfully logged in with your SSH key and that you have a way to access the server if something goes wrong (e.g., a console access provided by your hosting provider).

Hardening Your SSH Server

Beyond disabling password authentication, there are several other measures you can take to make your SSH server more secure.

Changing the Default SSH Port

The default SSH port is 22. While not a foolproof security measure, changing it can reduce the number of automated bot attacks that scan port 22 for vulnerable servers.

Edit /etc/ssh/sshd_config again:

sudo nano /etc/ssh/sshd_config
Enter fullscreen mode Exit fullscreen mode

Find the line #Port 22 and change it to your desired port, for example, Port 2222. Make sure to choose a port that isn't already in use by another service.

After changing the port, you'll need to restart the SSH service:

sudo systemctl restart sshd
Enter fullscreen mode Exit fullscreen mode

When connecting from your client, you'll now need to specify the new port:

ssh -p 2222 username@your_server_ip
Enter fullscreen mode Exit fullscreen mode

Remember to update any firewall rules to allow traffic on your new SSH port.

Disabling Root Login

Directly logging in as the root user is generally discouraged. It's better to log in as a regular user and then use sudo to perform administrative tasks.

In /etc/ssh/sshd_config, find or add the following line:

PermitRootLogin no
Enter fullscreen mode Exit fullscreen mode

Restart the SSH service after making this change.

Limiting User Access

You can specify which users or groups are allowed to log in via SSH. This is useful for restricting access to specific personnel.

In /etc/ssh/sshd_config, you can use AllowUsers or AllowGroups:

To allow only specific users:

AllowUsers user1 user2
Enter fullscreen mode Exit fullscreen mode

To allow only users in a specific group:

AllowGroups sshusers
Enter fullscreen mode Exit fullscreen mode

Remember to restart the SSH service after these changes.

Using Fail2Ban

Fail2Ban is an intrusion prevention software framework that protects your server by monitoring log files (e.g., /var/log/auth.log) for malicious activity, such as repeated failed login attempts. When it detects suspicious patterns, it can automatically update firewall rules to block the offending IP addresses for a configurable amount of time.

First, install Fail2Ban:

# For Debian/Ubuntu
sudo apt update
sudo apt install fail2ban

# For CentOS/RHEL
sudo yum install epel-release
sudo yum install fail2ban
Enter fullscreen mode Exit fullscreen mode

Then, start and enable the service:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban
Enter fullscreen mode Exit fullscreen mode

Fail2Ban comes with default configurations. For customization, you should copy the main configuration file to a local version to avoid your changes being overwritten during updates:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Enter fullscreen mode Exit fullscreen mode

Now, edit jail.local to configure specific jails and settings. For SSH, the relevant section usually looks like this:

[sshd]
enabled = true
port    = ssh
# Replace 'ssh' with your custom SSH port if you changed it
# port    = 2222
filter  = sshd
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h
findtime = 10m
Enter fullscreen mode Exit fullscreen mode
  • enabled = true: Activates the SSH jail.
  • port: Specifies the SSH port.
  • maxretry: The number of failed attempts before an IP is banned.
  • bantime: How long an IP is banned (e.g., 1h for one hour).
  • findtime: The time window within which maxretry must occur for an IP to be banned.

After editing jail.local, restart Fail2Ban:

sudo systemctl restart fail2ban
Enter fullscreen mode Exit fullscreen mode

You can check the status of Fail2Ban and its jails with:

sudo fail2ban-client status
sudo fail2ban-client status sshd
Enter fullscreen mode Exit fullscreen mode

Choosing a Hosting Provider

When setting up and managing servers, reliable hosting is key. I've had good experiences with providers like PowerVPS and Immers Cloud. Both offer a range of services suitable for developers, from basic VPS to more specialized solutions.

For those looking to explore different server rental options and compare features, the Server Rental Guide is a fantastic resource that breaks down various providers and their offerings.

Conclusion

Securing your SSH access with keys and hardening your SSH server configuration are fundamental steps for any server administrator or developer. By following these practices, you significantly reduce your server's attack surface, protect your data, and improve the overall security posture of your infrastructure. Remember to always test your changes thoroughly, especially after disabling password authentication, and keep your server software updated.

Top comments (0)