Learning AlmaLinux - SSH Hardening & Remote Access

#Introduction

In the previous episode, Episode 13, we secured the system from the inside with SELinux. Now we secure the front door: SSH. For most AlmaLinux servers, SSH is the only access path — and therefore the primary target of brute-force attacks on the internet. A freshly installed server directly exposed to the internet can receive thousands of login attempts in a single day.

This episode guides you from safe basic configuration to advanced hardening: ed25519 keys, disabling passwords, conditional rules, tunneling, and Fail2ban.

#Modern OpenSSH Configuration

The SSH configuration lives in /etc/ssh/sshd_config — a file that must be edited carefully, because a syntax error can lock you out of your own server.

#A Safe Configuration Baseline

Port 22
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3
AllowUsers devops ansible
Protocol 2

Every line has a reason:

• PermitRootLogin no — closes the direct root login door; admins log in as a regular user then sudo.
• PasswordAuthentication no — accepts only public key authentication; eliminates password brute-force attacks.
• MaxAuthTries 3 — limits authentication attempts per connection.
• AllowUsers — whitelist of users allowed to log in; everyone else is rejected.

Verify the configuration before restarting:

sudo sshd -t
sudo systemctl restart sshd

#Authenticating with Ed25519 Keys

Key authentication is the foundation of modern SSH. ed25519 is the newest public key algorithm — faster and more secure than RSA for general use.

#Generating and Installing Keys

ssh-keygen -t ed25519 -a 100

The -a 100 flag strengthens the KDF (Key Derivation Function) — more resistant to key-password brute-force. The output shows the private key file (~/.ssh/id_ed25519) and public key (~/.ssh/id_ed25519.pub).

ssh-copy-id -i ~/.ssh/id_ed25519.pub devops@server

ssh-copy-id adds the public key to ~/.ssh/authorized_keys on the destination server. After this succeeds, passwordless login works — and you can turn off PasswordAuthentication.

#Verifying Passwordless Login

ssh devops@server

If the login succeeds immediately without asking for a password, the key configuration is correct and it's safe to disable password authentication.

#Conditional Rules with Match

Match enables different rules for specific users, groups, or addresses — the core of granular access policies:

Match User backup
    PasswordAuthentication yes
    AllowTcpForwarding no
 
Match Group developers
    MaxSessions 5

The backup user is allowed to log in with a password (because scripting needs it) but cannot forward ports; the developers group is limited to 5 parallel sessions. Match must be at the end of the file, and all lines after it apply to that condition.

#Tunneling and Port Forwarding

SSH isn't just for login — it's also an encrypted data transfer medium.

#Local Forwarding

Access a service on the server from your local machine as if it were running locally:

ssh -L 8080:localhost:80 devops@server

After this, opening http://localhost:8080 on your local machine reaches port 80 on the server through an encrypted SSH tunnel — without opening port 80 on the public firewall.

#Dynamic Forwarding (SOCKS)

A SOCKS proxy on the local machine that forwards traffic through the server:

ssh -D 1080 devops@server

#Additional Hardening

#Fail2ban

Fail2ban monitors failed login logs and automatically blocks suspicious IP addresses:

sudo dnf5 install -y fail2ban
sudo systemctl enable --now fail2ban

[sshd]
enabled = true
maxretry = 5
bantime = 3600
findtime = 600

These settings block an IP for 1 hour after 5 failed attempts within 10 minutes. Verify the status:

sudo fail2ban-client status sshd

#Strict Key Policies

/etc/ssh/sshd_config can also enforce specific key policies. Make sure no dangerous options are on keys in authorized_keys — and restrict allowed algorithms to ed25519 only:

HostKeyAlgorithms ssh-ed25519
PubkeyAcceptedAlgorithms ssh-ed25519

#Common Pitfalls

1. Closing the SSH session before testing new configuration. Always test from a separate session — never lock yourself out.
2. Disabling PasswordAuthentication before the key is installed. Make sure ssh-copy-id succeeded first.
3. Using RSA 2048. Switch to ed25519, which is faster and more secure.
4. Leaving root login enabled. Set PermitRootLogin no and get used to sudo.
5. Disabling Fail2ban because it's "annoying". A block that feels annoying is a sign Fail2ban is protecting you.

#Conclusion

In this episode 14 you've secured AlmaLinux's main access path: modern sshd configuration with PermitRootLogin no and PasswordAuthentication no, ed25519 key authentication, Match conditional rules, port forwarding and SOCKS tunnels, plus hardening with Fail2ban, AllowUsers, and MaxAuthTries.

Key takeaways:

• Safe baseline: PermitRootLogin no, PasswordAuthentication no, MaxAuthTries 3, AllowUsers.
• Generate keys with ssh-keygen -t ed25519, install with ssh-copy-id.
• Use Match for per-user or per-group policies.
• ssh -L for local forwarding, ssh -D for a SOCKS proxy.
• Fail2ban automatically blocks IPs that repeatedly fail login.
• Always test sshd -t and keep a backup session when changing configuration.

With SSH locked down tight, you can think about the next layer. In the next episode, Episode 15, we'll cover TLS, Certificates & PKI — generating keys and CSRs with OpenSSL, self-signed vs CA-signed, the trust store with update-ca-trust, Let's Encrypt with certbot, and an introduction to simple PKI. See you there!