SSH Hardening — Securing Remote Access to Linux Systems¶
SSH Hardening is the process of securing the Secure Shell (SSH) service to reduce the risk of unauthorized access and attacks. Since SSH is the primary method for remotely administering Linux servers, it is a common target for attackers. Proper SSH hardening involves disabling insecure authentication methods, limiting access, enforcing strong authentication, and monitoring login activity. Every Linux administrator, DevOps engineer, Cloud Architect, Platform Engineer, and Site Reliability Engineer (SRE) should understand how to secure SSH in production environments.
Learning Path¶
Course Progress
What You'll Learn¶
After completing this lesson, you'll be able to:
- Understand SSH security risks
- Secure the SSH server configuration
- Disable root login
- Configure key-based authentication
- Disable password authentication
- Change SSH settings securely
- Restrict SSH access
- Apply production SSH hardening best practices
Prerequisites¶
Complete:
- Modules 1–10 of Linux Mastery
Why Learn SSH Hardening?¶
Imagine a production server exposed to the Internet.
Default configuration:
A hardened configuration:
Hardening significantly reduces the attack surface.
What is SSH Hardening?¶
SSH hardening is the process of configuring the SSH service to improve security.
Objectives include:
- Prevent unauthorized access
- Reduce attack surface
- Enforce strong authentication
- Protect administrative accounts
- Improve auditing
SSH Configuration File¶
The OpenSSH server configuration file is:
View it:
Always create a backup before making changes.
Disable Root Login¶
Allow administrators to log in using a regular account and elevate privileges with sudo.
Configuration:
Restart SSH.
or
(depending on the Linux distribution)
Disable Password Authentication¶
Use SSH keys instead of passwords.
Configuration:
This prevents password-based brute-force attacks.
Important
Verify SSH key authentication works before disabling password authentication.
Enable Public Key Authentication¶
Ensure public key authentication is enabled.
Restrict SSH Users¶
Allow only specific users.
Or allow specific groups.
This limits who can log in through SSH.
Disable Empty Passwords¶
Never allow accounts without passwords.
Configure Login Grace Time¶
Limit the time allowed for authentication.
Example:
Limit Authentication Attempts¶
Reduce brute-force opportunities.
After three failed attempts, the connection is closed.
Limit Concurrent Sessions¶
Example:
This helps prevent abuse.
Change the Default SSH Port¶
Default:
Example:
Changing the port may reduce automated scanning but should not be considered a replacement for proper security controls such as key-based authentication, firewall rules, and account restrictions.
Use Strong SSH Keys¶
Generate an Ed25519 key pair.
Or generate an RSA key.
Ed25519 is generally recommended for new deployments due to its strong security and smaller key size.
Disable X11 Forwarding¶
Unless required:
Disable TCP Forwarding¶
If unnecessary:
Enable Client Keepalive¶
Disconnect inactive sessions.
Inactive sessions are automatically closed.
Verify SSH Configuration¶
Check for syntax errors.
No output indicates the configuration is valid.
Restart the SSH Service¶
Ubuntu/Debian:
RHEL/CentOS:
Test Before Closing Your Session¶
Always open a new terminal and verify that you can log in successfully before closing your existing SSH session. This helps prevent accidentally locking yourself out of the server.
Common Commands¶
View configuration.
Validate configuration.
Restart service.
Generate SSH key.
Check SSH service.
Real Production Examples¶
Disable root login.
Disable password authentication.
Restrict users.
Generate SSH keys.
Production Perspective¶
SSH hardening is essential for:
- Linux servers
- Cloud virtual machines
- Kubernetes nodes
- Bastion hosts
- Database servers
- Production web servers
- Enterprise infrastructure
- Remote administration
A hardened SSH configuration significantly reduces the likelihood of unauthorized access.
Hands-on Lab¶
Task 1¶
Backup the SSH configuration.
Task 2¶
View the configuration.
Task 3¶
Disable root login.
Task 4¶
Disable password authentication.
Task 5¶
Restrict SSH users.
Replace youruser with your actual username.
Task 6¶
Validate the configuration.
Task 7¶
Restart the SSH service.
or
Task 8¶
Open a new terminal and verify that SSH login works before closing your current session.
Command Deep Dive¶
| Command | Purpose | Production Example |
|---|---|---|
ssh-keygen | Generate SSH keys | Secure authentication |
sshd -t | Validate configuration | Prevent configuration errors |
systemctl restart ssh | Restart SSH service | Apply changes |
systemctl status ssh | Check service status | Troubleshooting |
cp | Backup configuration | Change management |
nano | Edit configuration | Administration |
Common SSH Hardening Mistakes¶
| Mistake | Solution |
|---|---|
| Disabling passwords before configuring SSH keys | Verify key-based login first |
| Forgetting to validate configuration | Run sshd -t |
| Locking yourself out | Test in a new session |
| Allowing root login | Disable PermitRootLogin |
| Allowing unlimited login attempts | Configure MaxAuthTries |
Production Troubleshooting Scenario¶
Scenario
An administrator disables password authentication but forgets to configure SSH keys.
Result:
Correct approach:
- Generate SSH keys.
- Copy the public key to the server.
- Verify key-based login in a new terminal.
- Disable password authentication.
- Restart the SSH service.
This sequence ensures uninterrupted administrative access.
Best Practices¶
- Disable direct root login.
- Use SSH key authentication.
- Disable password authentication after verifying keys.
- Restrict SSH access to authorized users or groups.
- Limit authentication attempts.
- Validate configuration before restarting the service.
- Test changes in a new session before disconnecting.
- Keep OpenSSH updated with security patches.
Common Mistakes¶
❌ Leaving root login enabled.
✅ Do not leave root login enabled.
❌ Using password authentication in production.
✅ Avoid using password authentication in production when a safer approach exists.
❌ Not backing up the SSH configuration before editing.
✅ Always backing up the SSH configuration before editing.
❌ Restarting SSH without validating the configuration.
✅ Avoid this mistake: restarting SSH without validating the configuration.
❌ Closing the active SSH session before testing new settings.
✅ Avoid this mistake: closing the active SSH session before testing new settings.
Interview Questions¶
Beginner¶
- What is SSH?
- Why should root login be disabled?
- What is the purpose of SSH key authentication?
- Which file stores the SSH server configuration?
Intermediate¶
- Why is key-based authentication more secure than passwords?
- What does
MaxAuthTriesdo? - Why should
sshd -tbe run before restarting SSH? - What is the purpose of
AllowUsers?
Architect Level¶
- How would you securely manage SSH access across hundreds of Linux servers?
- How would you design a secure bastion host architecture?
- What SSH hardening controls would you require for production cloud environments?
Summary¶
In this lesson, you learned:
- SSH hardening fundamentals
- SSH server configuration
- Disabling root login
- Key-based authentication
- Restricting SSH access
- Limiting authentication attempts
- Validating configuration
- Production SSH security best practices
SSH is one of the most critical services on a Linux server and is often the primary entry point for administrators. Properly hardening SSH reduces the attack surface, strengthens authentication, and helps protect production systems from unauthorized access.
Key Takeaways¶
- Disable direct root login.
- Prefer SSH keys over passwords.
- Restrict SSH access to authorized users.
- Validate configuration before restarting the SSH service.
- Always test changes in a new session.
- Combine SSH hardening with firewalls, monitoring, and regular security updates for a layered defense.
What's Next?¶
File Permissions Review — Securing Files and Directories in Linux
You'll explore:
- Linux permission model
- Ownership and permissions
- Numeric and symbolic permissions
- Special permissions (SUID, SGID, Sticky Bit)
- Secure permission practices
- Permission auditing
- Production security examples
By the end of the lesson, you'll be able to review, audit, and secure file permissions to protect Linux systems from unauthorized access and accidental modifications.