Amar Vyas

SSH Server Hardening - Lock Down Your Remote Machine

2025-01-24 · Commandline · 6 min read

You own the server. You own the risk. This final part covers Debian-specific sshd_config hardening, firewall rules, and failover-safe restart procedures. Before you begin, make sure your client key is ready. If you have not generated one yet, read Part 2 first. If the server refuses your key after a config change, you may lose access entirely.

Summaries

English Secure your Debian server by hardening OpenSSH. This guide covers installing the server, managing authorized_keys, and editing /etc/ssh/sshd_config to disable root login and password authentication. You will whitelist users with AllowUsers, configure UFW, set connection timeouts, and test changes safely. We also introduce Fail2Ban for automated brute-force protection. By the end, your SSH service will be lean, hardened, and resistant to common attacks without sacrificing legitimate access.

Hindi Summary:
अपने Debian सर्वर को OpenSSH हार्डनिंग से सुरक्षित करें। सर्वर इंस्टॉलेशन, authorized_keys प्रबंधन, और /etc/ssh/sshd_config संपादन सीखें ताकि रूट लॉगिन और पासवर्ड प्रमाणीकरण अक्षम हो सके। AllowUsers से उपयोगकर्ता व्हाइटलिस्ट करना, UFW फ़ायरवॉल नियम, और कनेक्शन टाइमआउट सेट करना सीखें। Fail2Ban से ब्रूट-फोर्स प्रयासों को रोकने का तरीका भी शामिल है। अंत में, आपका सर्वर अनावश्यक जोखिमों को अस्वीकार करते हुए सुरक्षित बना रहेगा।

SSH Server Hardening on Debian: Lock Down Your Remote Machine

Debian typically installs OpenSSH server by default on minimal systems, but not always.

Installation

If it is missing:

sudo apt update && sudo apt install openssh-server

Enable and Start

Ensure it runs now and on every boot:

sudo systemctl enable --now ssh

Debian Service Name Note

On Debian, the systemd service is named ssh, not sshd. You manage it with systemctl status ssh or systemctl restart ssh. The underlying binary is still sshd, which matters when validating configuration.

Server-Side Key Authentication

Before you disable passwords, confirm that key-based login works from your client.

The authorized_keys File

Each user who needs key access must have their public key in ~/.ssh/authorized_keys on the server. Paste the contents of your local id_ed25519.pub here, one key per line.

Fix Permissions on the Server

SSH on Debian is strict. Run these on the server as the target user:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If the permissions are too open, the server will ignore the key and fall back to password authentication.

Test Before You Disable Passwords

Open a new terminal on your client and verify passwordless login works:

ssh vyas@server-ip

Only proceed to the next section after this succeeds.

Hardening /etc/ssh/sshdconfig

This is the main configuration file for the SSH daemon. Edit it with root privileges:

sudo nano /etc/ssh/sshd_config

Disable Root Login

Prevent direct root access over SSH:

PermitRootLogin no

If you are nervous, use prohibit-password as an intermediate step. It allows root only with keys. For single-user setups, no is best.

Disable Password Authentication

Force all users to use keys:

PasswordAuthentication no

Enforce Public Key Authentication

Ensure the server accepts keys:

PubkeyAuthentication yes

Whitelist Users

Explicitly name who may log in. Everyone else is rejected immediately:

AllowUsers vyas

You can list multiple users separated by spaces. If you manage several accounts, this is your fastest safety net.

Optional Custom Port

Changing the default port from 22 to another number reduces automated bot noise. It does not stop a targeted attacker.

Port 2222

If you change this, remember to use -p 2222 on the client, or specify it in your ~/.ssh/config as shown in Part 3. You must also update your firewall.

Connection Timeouts and Firewall

Hard configuration means little if the firewall leaves the door open or abandoned sessions pile up.

Prevent Hung Sessions

Add these to /etc/ssh/sshd_config to close idle connections:

ClientAliveInterval 300
ClientAliveCountMax 2

The server checks every 300 seconds and drops the connection after two missed responses.

Limit Auth Attempts

Reduce brute-force noise:

MaxAuthTries 3

Allow SSH Through UFW

Debian uses UFW as a simple firewall wrapper. Allow your SSH port before enabling the firewall, or you will lock yourself out.

For the default port:

sudo ufw allow 22/tcp

For a custom port:

sudo ufw allow 2222/tcp

Enable it:

sudo ufw enable
sudo ufw status

Restart Safely

Never restart the SSH service blindly. A typo in sshd_config can lock every admin out until physical console access is restored.

Validate Syntax

Check for errors before applying:

sudo sshd -t

If there is no output, the configuration is valid.

Restart the Service

On Debian:

sudo systemctl restart ssh

The Golden Rule

Keep your current SSH session open. Open a second terminal and confirm you can still log in. Only close the first session after the new one works. If you are locked out, the old session is your rescue line.

Extra Protection with Fail2Ban

For servers exposed directly to the internet, automated attacks are constant.

What It Does

Fail2Ban monitors your SSH logs. After a defined number of failed login attempts, it bans the source IP address at the firewall level.

Quick Install

sudo apt install fail2ban

It usually enables SSH protection by default on Debian. Verify it is active:

sudo systemctl status fail2ban

This is your final automated net. Combined with disabled passwords and AllowUsers, it makes most attackers move on.

Conclusion

Server hardening is a checklist, not a mystery. Disable root login, drop passwords, whitelist your users, and add a firewall. Test every change before closing your last working session.

You now have a secure, lean SSH service on Debian. Your client is configured from Part 3, and your server is locked from Part 4.

Key Takeaways:

  • Always test with sudo sshd -t before restarting.
  • Keep one working SSH session open while testing any change.
  • AllowUsers is your fastest user-level lock.
  • Disable PasswordAuthentication only after confirming key login works.
  • Fail2Ban is the final automated defense for public-facing servers.

Additional Sections

FAQ Section:

1. I changed sshd_config and locked myself out. Now what? Use your hosting provider's web console or VNC rescue system. This is why you always keep one working SSH session open during testing.
2. Is changing the SSH port enough to stop hackers? No. It only reduces automated bot log noise. Real security comes from key-only authentication, disabled root, and user whitelisting.
3. Should I use PermitRootLogin prohibit-password instead of no? prohibit-password is a safer intermediate step if you rely on root keys, but for most single-user VPS setups, no is best.

Call-to-Action:

You have completed the Debian SSH Mastery series. If you are new, return to Part 1 for the fundamentals, or review Part 3 to keep your client configuration sharp.

Links and Resources

Internal Links:

External Links:

This post was published under Commandline and last updated on 2026-07-21 .