Linux Server Deployment & SSH Mastery · Lesson

Hardening the SSH Server

Lock down your SSH server by editing sshd_config: disable root and password logins, change risky defaults, restrict users, and apply layered protections so only trusted clients can connect.

Hardening the SSH Server is a free Linux Server Deployment & SSH Mastery lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Linux Server Deployment & SSH Mastery learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Harden SSH?

An SSH server exposed to the internet is a constant target for automated attacks. Default settings leave several doors open that bots probe relentlessly.

Hardening means tightening the server-side configuration so that even if attackers find your server, they cannot brute-force their way in.

The sshd_config File

Server-side SSH behavior is controlled by /etc/ssh/sshd_config. This is different from the client config you configured earlier (~/.ssh/config).

Always edit it as root and keep a backup before making changes.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Disable Root Login

The root account is the first thing attackers try. Disabling direct root login forces them to also guess a valid username.

Set PermitRootLogin to no. Administrators should log in as a normal user and use sudo.

PermitRootLogin no

Disable Password Authentication

Once you have key-based auth working, turn off passwords entirely. This defeats brute-force attacks completely — there is no password to guess.

Warning: confirm your key login works before applying this, or you may lock yourself out.

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

Restrict Who Can Log In

You can whitelist exactly which accounts may use SSH with AllowUsers or AllowGroups. Anyone not listed is refused even with valid keys.

This is a strong, simple control on multi-user servers.

AllowUsers deploy admin
# or by group:
AllowGroups sshusers

Change the Default Port (Optional)

Moving SSH off port 22 does not add real security, but it dramatically cuts the noise from automated scanners in your logs.

Pick a non-standard port and remember to open it in your firewall and tell your clients about it.

Port 2222

Limit Login Attempts and Sessions

Several directives reduce the window attackers have:

MaxAuthTries — failed attempts before disconnect
LoginGraceTime — seconds allowed to authenticate
MaxSessions — concurrent sessions per connection

MaxAuthTries 3
LoginGraceTime 30
MaxSessions 2

Apply Changes Safely

After editing, validate the syntax with sshd -t before restarting — a typo can stop the service from starting and lock you out.

Then reload the service. Keep your current session open and test a new connection before closing it.

sudo sshd -t
sudo systemctl restart ssh

Protect Against Brute Force with Fail2ban

Fail2ban watches your auth logs and temporarily bans IPs that fail too many times. It adds a dynamic firewall layer on top of sshd settings.

Install it and enable the SSH jail; defaults are sensible for most servers.

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Verify Your Hardening

Confirm the server now rejects the things you disabled. Try connecting with verbose output to see which auth methods the server offers.

A hardened server should advertise only publickey and refuse password and root logins.

ssh -v deploy@server
# Look for: 'Authentications that can continue: publickey'

Best Practices

Keep your SSH server safe over time:

Never apply PasswordAuthentication no before testing key login
Keep one open session while changing config
Use sshd -t on every edit
Combine sshd hardening with a firewall and Fail2ban

Quick Check

Test your SSH hardening knowledge.

Recap

You hardened your SSH server through /etc/ssh/sshd_config:

Disabled root and password logins
Whitelisted users with AllowUsers
Tuned MaxAuthTries and LoginGraceTime
Added Fail2ban for dynamic brute-force protection

Validate with sshd -t and always test before closing your session.

Frequently asked questions

Is the “Hardening the SSH Server” lesson free?

Yes — the full text of “Hardening the SSH Server” is free to read here on the web, and the Linux Server Deployment & SSH Mastery course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Linux Server Deployment & SSH Mastery course, upgrade to CoddyKit PRO.

What will I learn in “Hardening the SSH Server”?

Lock down your SSH server by editing sshd_config: disable root and password logins, change risky defaults, restrict users, and apply layered protections so only trusted clients can connect. You practise Linux Server Deployment & SSH Mastery with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Linux Server Deployment & SSH Mastery?

No prior experience is required. Linux Server Deployment & SSH Mastery on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Hardening the SSH Server” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Linux Server Deployment & SSH Mastery lesson?

Yes. Every Linux Server Deployment & SSH Mastery lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Linux Server Deployment & SSH Mastery