3.7.3 SSH security basics

Introduction

Secure Shell, usually called SSH, is the standard way to manage Linux systems remotely using an encrypted connection. In basic terms, it replaces insecure tools like telnet that send everything, including passwords, in plain text. This chapter focuses on the practical security aspects of SSH for an administrator who already knows what SSH is at a high level, and wants to harden a server that uses it.

How SSH Authentication Works

SSH protects two things at once. It encrypts all traffic between client and server, and it verifies who you are. From a security perspective, how you authenticate is critical.

There are two common authentication methods you will work with: password authentication and public key authentication. Password logins are simple to set up but weaker. Public key authentication is strongly recommended for administrative access.

In password authentication, the client sends a proof of the password through the encrypted channel and the server checks it against the user database. Attackers can attempt to guess the password, which makes this method vulnerable to brute force attacks and weak password choices.

In public key authentication, you generate a key pair: a private key that stays with you, and a public key that you copy to the server. When you connect, the server checks that you prove possession of the private key that matches the stored public key, without ever seeing the private key directly. This is much harder to brute force and allows you to disable password logins entirely.

Generating and Managing SSH Keys

On most Linux systems, ssh-keygen is used to generate key pairs. There are several algorithms, but for typical administration you will often use ed25519 or rsa. ed25519 is modern and usually preferred for new setups.

To create an Ed25519 key pair:

ssh-keygen -t ed25519 -C "your_email@example.com"

The command will ask you where to save the key and whether you want to use a passphrase. A passphrase protects the private key if your local machine is compromised. For sensitive administrative keys, you should use a passphrase, then rely on an agent like ssh-agent to cache the decrypted key in memory once you type the passphrase.

The generated files usually appear in ~/.ssh. A default Ed25519 key pair would be:

~/.ssh/id_ed25519 for the private key
~/.ssh/id_ed25519.pub for the public key

You must keep the private key secret and never copy it to any server. The public key can be shared freely for authentication purposes.

On the server, the public keys that can log in as a user are stored in ~/.ssh/authorized_keys for that user. To allow key based login for a user, you append the client’s public key to that file. For example:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions on this directory and file matter. SSH will refuse to use keys if files are too permissive, because that would be unsafe. Using restrictive permissions, such as 700 for ~/.ssh and 600 for authorized_keys, is a basic requirement.

Basic SSH Client Security Practices

Security for SSH is not only about the server. The security of your client machine also matters.

You should protect your private key with a passphrase. Without a passphrase, anyone who gets a copy of the private key can log in as you on any server that trusts that key. With a passphrase, the attacker must know or guess the passphrase as well.

To manage passphrase protected keys conveniently, you can run an SSH agent. An agent stores your decrypted private keys in memory after you unlock them once. The client programs then ask the agent to sign authentication requests. On many desktop environments, an SSH agent is started automatically.

On the client side, the file ~/.ssh/config can define host specific settings, such as which key to use for which server, or custom ports. For example:

Host myserver
    HostName example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519

This file should also have strict permissions, typically 600, so that other users cannot read your configuration and potential sensitive paths or usernames.

Server Side SSH Configuration File

On most Linux distributions that use OpenSSH, the main server configuration file is /etc/ssh/sshd_config. This file controls how the SSH daemon accepts connections, which methods of authentication are allowed, and various security related limits.

When you edit this file, you must restart or reload the SSH service for changes to take effect. For example, on a system using systemd:

sudo systemctl reload sshd

or on some distributions:

sudo systemctl reload ssh

Always keep an active SSH session open while you test new settings, so you can revert changes if you lock yourself out.

Hardening Authentication: Keys vs Passwords

One of the most important security decisions is how users authenticate.

If you are using key based authentication and you have confirmed it works, you can restrict or disable password authentication. In sshd_config, the following settings are typical for a hardened setup:

PasswordAuthentication no
PubkeyAuthentication yes

With PasswordAuthentication no, users cannot log in using passwords. Only keys in authorized_keys are accepted. This blocks a large class of automated brute force attacks that simply try username and password combinations.

If you still need passwords for some users, you can keep password authentication enabled and combine it with other measures, such as strong password policies and connection rate limiting. However, that is weaker than using keys alone.

You can also control whether root is allowed to log in directly. For example, you may have:

PermitRootLogin prohibit-password

This setting allows root to log in with keys, but not with a password. For stricter setups, you might use:

PermitRootLogin no

which forces you to log in as a regular user and then use sudo for administrative tasks. This reduces the exposure of the root account.

Port and Address Settings

By default, SSH listens on TCP port 22 on all network interfaces. Attackers commonly scan port 22 across the internet. Changing the port does not provide real security, but it can reduce noise from automated attacks and log clutter. This is called security by obscurity and should only be an additional minor measure, not a replacement for proper hardening.

To change the port in sshd_config, you can set:

Port 2222

After modifying this, you must adjust any firewall configuration so that the new port is accessible, then reload the SSH service.

In some setups you might restrict which network addresses the SSH server listens on. For example, if the server is inside a private network and should only accept connections from that network, you can set:

ListenAddress 192.168.1.10

This helps reduce exposure to unwanted networks. You must be careful to choose the correct addresses or you may prevent legitimate access.

Limiting Who Can Log In

You can control which users and groups are allowed to log in with SSH. This is a simple but effective way to limit the impact of credential leaks and brute force attacks.

In sshd_config, the directives AllowUsers, DenyUsers, AllowGroups, and DenyGroups define access control lists. For example:

AllowUsers admin backupuser
AllowGroups sshusers

In this setup, only the specified users or users in the group sshusers can log in. Everyone else will be rejected even if they have valid passwords or keys.

If you want to block specific users, such as service accounts that should never have remote shell access, you can use:

DenyUsers ftpuser dbuser

or place those accounts in a group that is denied.

Because these directives are evaluated in a specific order, you should keep your rules simple to avoid confusion. Typically, you either use only allow lists or only deny lists, not a complex combination.

Restricting What Users Can Do

Sometimes you need to give someone SSH access only for a limited purpose, and you do not want them to have a full shell. SSH can be configured to restrict commands in several ways.

One simple approach is to specify forced commands in authorized_keys. When you add a public key to authorized_keys, you can prefix it with options. For example:

command="/usr/local/bin/backup-script.sh" ssh-ed25519 AAAA...

With this line, whenever that particular key is used to authenticate, the user cannot run arbitrary commands. Instead, the SSH server will always run /usr/local/bin/backup-script.sh. This is useful for automation tasks that should have tightly controlled behavior.

You can also use restricted shells or chroot based setups to confine users, but those topics belong to more advanced access control techniques beyond the basics.

Protecting Against Brute Force and Abuse

SSH is a very common target for automated attacks that try to guess passwords or usernames. Even if you use keys, these attempts will fill your logs and can consume resources. Several simple measures help mitigate this.

Using key based authentication and disabling password logins removes the main target of brute force attempts, which is the password check. Attackers can still open connections, but they cannot succeed without the correct key.

Limiting which users can log in reduces the number of accounts that can be attacked. Removing SSH access from system accounts reduces the attack surface.

Network level protections such as firewall rules and tools that block repeated failed attempts are important. For example, some administrators use tools that watch log files and temporarily block IP addresses that cause repeated failures. While the implementation details belong elsewhere, you should understand that SSH hardening is more effective when combined with these network level controls.

From a configuration point of view, you can also limit authentication attempts per connection. In sshd_config:

MaxAuthTries 3

reduces the number of password or key attempts allowed before the server disconnects the client. Lowering this value makes brute forcing multiple passwords per connection harder.

Key Fingerprints and Host Verification

SSH also protects you from connecting to the wrong server. When you connect to a server for the first time, the SSH client shows the server’s host key fingerprint. If you accept it, the fingerprint is stored in ~/.ssh/known_hosts. On future connections, the client compares the server’s key to the stored fingerprint.

If the key changes unexpectedly, you get a warning. This might indicate a reinstalled server, a new configuration, or a man in the middle attack that is pretending to be your server. You should not automatically ignore such warnings. Instead, verify with a trusted source what the correct host key fingerprint should be.

You can display the host key fingerprints on the server using a command like:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

This prints a fingerprint that you can compare with what the client reports. Verifying fingerprints is a basic, but often overlooked, security step when you first connect to an important server.

Keeping SSH Software Updated

The security of SSH also depends on the version of the SSH server and client software. Vulnerabilities can exist in older versions, and these are usually fixed in updates provided by your distribution.

As part of your regular system updates, ensure that the openssh-server and openssh-client packages stay current. You do not need to reconfigure SSH after every update, but you should be aware that security fixes may be applied silently when you perform routine package upgrades.

It is also a good practice to remove unneeded authentication methods or obsolete ciphers from your configuration when your distribution deprecates them. This reduces the chance that an attacker can force the use of a weak cryptographic method. Exact cipher lists and policies depend on the version and distribution, so it is usually best to follow your distribution’s security guidance rather than making arbitrary changes.

Summary

SSH security in practice focuses on three main ideas. You favor strong authentication using key pairs instead of passwords. You restrict access by controlling who can log in, how, and from where. You monitor and maintain the SSH service by keeping its software updated and responding to unusual connection attempts or host key warnings.

By carefully managing keys, adjusting sshd_config to disable unnecessary features, and combining SSH configuration with network level protections, you create a much more resilient remote access setup for your Linux systems.