When I first started managing Linux servers about fifteen years ago, one of the earliest ”security tips” everyone shared was changing SSH from port 22 to something obscure. It felt clever—like I was outsmarting potential attackers by hiding my front door. But after watching automated scanners hammer away at random high ports on my servers, I quickly realized that port obscurity alone wasn’t going to cut it.
Why Port 22 Gets All the Attention (And Why That’s Not Enough)
SSH runs on port 22 by default, making it an obvious target for automated attacks. Your server logs are probably filled with thousands of failed login attempts from bots systematically trying common usernames and passwords. Changing the port does reduce this noise—I’ve seen auth.log files shrink from hundreds of daily attempts to just a handful after moving SSH to a non-standard port.
But here’s the reality: changing your SSH port is security through obscurity, not actual security. Any determined attacker running a comprehensive port scan will find your SSH service regardless of which port it’s listening on. That’s exactly what PortVigil does—it scans all ports to identify what services are running and where they might be vulnerable.
The Real SSH Security Layers That Actually Matter
After managing dozens of Debian servers over the years, I’ve learned that proper SSH security is about building multiple defensive layers. Here’s what actually protects your servers:
Disable password authentication entirely. This single change eliminates the vast majority of SSH attacks. Use SSH keys instead—they’re essentially impossible to brute force. I made this switch across all my production servers years ago, and the difference in peace of mind is remarkable. Yes, it requires a bit more initial setup, but once your keys are in place, authentication is both more secure and more convenient.
Implement fail2ban or similar intrusion prevention. This tool monitors your logs and automatically blocks IP addresses that show suspicious behavior. I remember one incident where a particularly persistent bot was trying to connect every few seconds. Fail2ban caught it after five attempts and banned the IP for 24 hours. The attacks stopped immediately.
Use strong key algorithms. Older SSH configurations might still allow weak algorithms like DSA or RSA keys under 2048 bits. Modern best practice means using Ed25519 keys or at minimum 4096-bit RSA keys. I regenerated all my SSH keys last year when I learned that Ed25519 offers better security with smaller key sizes.
Configuration Hardening That Makes a Difference
Your SSH daemon configuration (usually at /etc/ssh/sshd_config) contains dozens of settings that dramatically impact security. Here are the changes I make to every new server:
Set PermitRootLogin to ”no”—always. There’s never a good reason to allow direct root login via SSH. Create a regular user account, grant it sudo privileges, and log in as that user instead. This adds accountability and makes it harder for attackers who are specifically targeting the root account.
Disable PasswordAuthentication as I mentioned earlier, but also disable ChallengeResponseAuthentication and UsePAM password authentication. Some configurations can bypass password restrictions through PAM if you’re not careful.
Set MaxAuthTries to 3 or fewer. Why give attackers more chances to guess credentials? Combined with fail2ban, this creates a strong barrier against brute force attempts.
Limit which users can actually SSH into your server using AllowUsers or AllowGroups. I typically create a specific ”ssh-users” group and only add accounts that genuinely need remote access.
Network-Level Protection
Beyond the SSH daemon itself, consider where SSH connections are actually coming from. If you’re managing servers from a fixed IP address or a small range of IPs, use firewall rules to restrict SSH access to only those addresses.
I use UFW (Uncomplicated Firewall) on my Debian servers, and a simple rule like ”ufw allow from 123.456.78.90 to any port 22” means SSH is only accessible from my office IP. For remote work scenarios, a VPN provides a similar layer of protection—SSH is only accessible from inside the VPN network.
Monitoring and Auditing
This is where external scanning services like PortVigil become invaluable. You need to know what ports are actually open and visible from the outside world. I run weekly scans on all my servers, and you’d be surprised how often legitimate services accidentally expose SSH to the entire internet when they should be firewalled.
Enable detailed SSH logging and actually review those logs periodically. Tools like logwatch can summarize SSH activity and alert you to unusual patterns. I once discovered an old development server that was still using password authentication because I reviewed the weekly logwatch summary and saw hundreds of failed attempts.
The Port Change Question Revisited
So should you change SSH from port 22? Honestly, it depends. If you’re managing a personal server and want to reduce log noise from automated scanners, sure—move it to a high port like 2222 or 50022. It’s a five-minute change in sshd_config.
But don’t fool yourself into thinking this is meaningful security. The servers I manage for my various web services all run SSH on port 22, and they’re perfectly secure because they use key authentication, fail2ban, firewall restrictions, and regular security audits.
Common Myths About SSH Security
Myth: Obscure ports can’t be found. False. A comprehensive port scan takes minutes and will identify SSH regardless of port number.
Myth: Strong passwords are enough. They’re not. Even a 16-character password can eventually fall to a sustained brute force attack or be compromised through other means. Keys are categorically better.
Myth: Default configurations are reasonably secure. They’re designed for compatibility, not security. A default SSH installation allows password authentication and often permits root login—both significant vulnerabilities.
Practical Implementation Steps
If you’re looking to actually secure your SSH access today, here’s the order I recommend:
1. Generate SSH keys if you haven’t already (ssh-keygen -t ed25519)
2. Copy your public key to the server (ssh-copy-id user@server)
3. Test that key authentication works before making changes
4. Edit sshd_config to disable password authentication
5. Restart the SSH daemon and verify you can still connect
6. Install and configure fail2ban
7. Set up firewall rules if you have a fixed IP range
8. Run an external port scan to verify your configuration
Securing SSH isn’t about one clever trick—it’s about implementing proven security practices in layers. Change the port if it makes you feel better, but focus your real effort on the authentication and access control mechanisms that actually stop attackers.