SSH Hardening: Why Changing Port 22 Is Just The Beginning Of Cloud Security + Video

Introduction:

In the relentless arena of cloud engineering and DevOps, the Secure Shell (SSH) protocol serves as the primary gateway to your infrastructure. While cryptography—specifically the blend of symmetric and asymmetric encryption—makes SSH inherently secure, its default configuration creates a massive attack surface. Servers exposed to the internet are constantly probed by automated bots targeting Port 22, leading to brute-force attacks and potential Denial of Service (DoS) scenarios. Understanding how to fortify SSH is not just a best practice; it is the foundational discipline of cyber hygiene.

Learning Objectives:

Understand the cryptographic principles (symmetric/asymmetric encryption) that underpin SSH security.
Analyze the threat landscape of default configurations, including DoS/DDoS attacks on Port 22.
Implement a multi-layered SSH hardening strategy, from port obfuscation to key-based authentication and firewall restriction.

You Should Know:

The Threat Landscape: Why Port 22 is a Battlefield
SSH relies on a handshake process that uses asymmetric encryption (public and private keys) to establish a secure session, which then uses symmetric encryption for faster data transfer. However, the default listening port for this service (Port 22) is a well-known vector. Attackers use port scanners to identify open Port 22 and launch dictionary attacks or brute-force login attempts. A Distributed Denial of Service (DDoS) attack can flood this port with traffic, consuming server resources and making it unavailable to legitimate users. Changing the default port reduces the “noise” of automated scans, but it is merely the first step in shrinking the attack surface.
Step‑by‑Step Guide: Changing the Default SSH Port (Linux)
This move obfuscates the service from basic bots. You will need root or sudo access.

Step 1: Backup the SSH Configuration File. Before making changes, create a backup to ensure you can revert if something goes wrong.
```
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
```
Step 2: Edit the Configuration File. Open the file with a text editor like `nano` or vim.
```
sudo nano /etc/ssh/sshd_config
```
Step 3: Modify the Port Directive. Find the line that says Port 22. Remove the “ to uncomment it and change the number to a high, unused port (e.g., 2222 or 2345). Avoid ports below 1024 unless necessary, as they are reserved for system services.
```
Port 2345
```
Step 4: Restart the SSH Service. Apply the changes by restarting the SSH daemon. Warning: Do not close your current session until you have tested the new port in a new terminal window.
```
sudo systemctl restart sshd
```
Step 5: Connect Using the New Port. From your client machine, specify the new port.
```
ssh -p 2345 username@your_server_ip
```

3. Step‑by‑Step Guide: Implementing Key-Based Authentication

Passwords are vulnerable to brute-force attacks. SSH keys, which utilize asymmetric encryption, provide a much stronger layer of defense.

Step 1: Generate a Key Pair on Your Local Machine. Use the `ssh-keygen` command. The `-t` flag specifies the type (RSA or ED25519 recommended), and `-b` specifies the bit length.
```
ssh-keygen -t ed25519 -C "[email protected]"
```
Follow the prompts to save the file (default: ~/.ssh/id_ed25519) and optionally set a passphrase for the key itself.
Step 2: Copy the Public Key to the Server. Use `ssh-copy-id` to securely install your public key on the server.
```
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2345 username@your_server_ip
```
Step 3: Disable Password Authentication on the Server. Edit the SSH config file again.
```
sudo nano /etc/ssh/sshd_config
```

Find and modify the following lines:

PasswordAuthentication no
ChallengeResponseAuthentication no

Step 4: Restart SSH and Test.
```
sudo systemctl restart sshd
```
Now, only users with the private key can log in, neutralizing brute-force password attacks.

4. Step‑by‑Step Guide: Disabling Root Login

Allowing direct root login is a critical vulnerability. Attackers know the username is “root”; they only need the password. You should log in as a regular user and escalate privileges only when needed.

Step 1: Edit the SSH Configuration.
```
sudo nano /etc/ssh/sshd_config
```
Step 2: Set the PermitRootLogin Directive. Ensure this line is set to no.
```
PermitRootLogin no
```
Step 3: Restart SSH.
```
sudo systemctl restart sshd
```
Step 4: Create a Sudo User (if not already done). If you haven’t created a regular user with admin rights, do so now.
```
sudo addusername newuser
sudo usermod -aG sudo newuser
```

Step‑by‑Step Guide: Restricting Access with Firewalls (UFW & iptables)
A firewall acts as the gatekeeper, allowing traffic only from trusted sources.

Using UFW (Uncomplicated Firewall) on Ubuntu:
Allow your new SSH port and deny the old one.

sudo ufw allow 2345/tcp comment 'SSH new port'
sudo ufw deny 22/tcp
sudo ufw enable
sudo ufw status verbose

Using iptables (General Linux):

Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Allow SSH on new port from a specific trusted IP (e.g., 192.168.1.100)
sudo iptables -A INPUT -p tcp --dport 2345 -s 192.168.1.100 -j ACCEPT
Set default policy to drop
sudo iptables -P INPUT DROP

6. Step‑by‑Step Guide: Monitoring Login Attempts (Fail2ban)

Fail2ban scans log files and bans IPs that show malicious signs, like too many password failures.

Step 1: Install Fail2ban.

sudo apt update && sudo apt install fail2ban -y

Step 2: Create a Local Configuration File. Copy the default config to a local one to avoid overwriting during updates.
```
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
```

Step 3: Configure the SSH Jail. Edit the `jail.local` file. Find the `

` section and enable it.
[bash]
[bash]
enabled = true
port = 2345 ; Ensure this matches your custom port
logpath = %(sshd_log)s
maxretry = 3
bantime = 3600 ; Ban for 1 hour

Step 4: Restart Fail2ban.

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

What Undercode Say:

Defense in Depth is Non-Negotiable: Changing the SSH port is a valid tactic to reduce noise, but it is security through obscurity. Relying on it alone is dangerous. True security lies in combining it with key-based authentication, strict user controls (disabling root), and active monitoring (Fail2ban).
Automation Fuels the Attack Surface: In the age of cloud and DevOps, servers are ephemeral and often misconfigured at launch. The constant scanning of IP space by bots means a misconfigured SSH daemon can be compromised within hours. Hardening must be baked into Infrastructure as Code (IaC) templates, not done as an afterthought.

The move from password-based logins to key-based systems is not just a technical upgrade; it represents a shift in trust from something you know (a password) to something you have (a private key). As cloud environments become more complex, managing these keys through SSH Agent or dedicated secrets management tools becomes critical. The server logs you monitor today will tell the story of the attacks you prevented yesterday. Ignoring SSH security is like leaving the front door of a bank wide open because you trust the vault—the perimeter must be resilient at every layer.

Prediction:

As quantum computing advances, the cryptographic algorithms currently used in SSH (like RSA) may become vulnerable. We will likely see a gradual shift toward post-quantum cryptography algorithms integrated directly into SSH implementations. Furthermore, with the rise of zero-trust architectures, the concept of a “server” with a persistent SSH port may diminish, replaced by ephemeral, just-in-time access brokers that eliminate the need for long-lived SSH daemons entirely.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Eze Linda – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post