SSH Penetration Testing: Strengthening Security & Transitioning to Ed25519

Introduction

Every network device or server, from routers to switches, has one essential feature: the console port. It’s the backbone of device administration, allowing access to configure and manage network appliances, from IOS Layer 3 devices and above. In today’s world, however, that console port has evolved — it now spans both hardware and software. Enter SSH: the modern-day console port.

While SSH is supported by nearly every Layer 3 device, providing secure, remote access, it also introduces a significant risk. If a threat actor gains even unprivileged access, the implications can be severe. This is why it’s critical to safeguard this access from growing threats, whether from brute-force attacks or outdated cryptographic algorithms. Without proper controls, the very protocol designed to secure access could become a weakness.

Why Move to Ed25519?

✅ Enhanced Security

Ed25519 is based on the Curve25519 elliptic curve, which is designed to avoid known vulnerabilities such as small subgroup attacks and invalid curve attacks. And because Ed25519 leverages a deterministic signing process, it eliminates the risk of vulnerabilities due to poor randomness in key generation.

This means that compared to traditional algorithms like RSA or DSA, Ed25519 is far more resilient against modern cryptographic attacks, including potential quantum computing threats.

⚡ Performance

Ed25519 is optimized for speed and efficiency. It allows for faster key generation and signature verification, making it ideal for high-performance environments. In fact, Ed25519 offers significant performance improvements over RSA and ECDSA in both signing and verification operations.

🔒 Compact Key Size

Ed25519 also has a much smaller key size and therefore reduces storage requirements and network overhead, which is beneficial for constrained environment.

Smaller key sizes also helps Ed25519 to resists side-channel attacks, such as timing attacks and cache attacks, that can leak sensitive information to attackers.

Best Practices for Ongoing SSH Security

Keeping up-to-date with the latest encryption algorithms is essential. However, on a personal level, I follow a few additional tricks to stay secure.

1. Know Your Network

You might assume that your internal servers and services within your LAN are safe from external attacks, and to some extent, you'd be right. If you're not hosting any public services and your router isn't vulnerable, your exposure is minimal.

However, with the rise of Malware and Ransomware in recent years, it is very possible for you to come across a malware that would silently worm into your lan simply to steal passwords and even SSH signing keys.

If you're hosting publicly accessible services, isolate them in a separate VLAN.

• IoT devices? Separate VLAN!
• Security cameras? Separate VLAN!
• Anything that isn't your personal device (like phones and laptops), isolate them.

For instance, if your IoT devices don't require internet access, simply remove the internet gateway or proxy server from that VLAN. This way, you control what communicates with the outside world.

And frequently monitor your internet network traffic, because it's far easier for a malware or hacker to create an outbound connection from your local devices than vice versa. Infact that is one of the first things an attacker would do to maintain a persistant connection to your infrastructure.

2. Change the Default SSH Port

One of the first things I do when setting up a server is to change the default SSH port (22) to something like 4022. While this doesn't prevent an attack it helps reduces automated bots and script kiddies scanning your ip to discover services.

This does not mean it is safe to expose your SSH ports to the internet, if for some reason you want to connect to your SSH Access remotely then make sure to follow additional setups below and/or better yet use a Zero Trust Tunnel instead.

3. Enforce 2FA for SSH Access

2FA (Two-Factor Authentication) should be by default your first layer of defence, regardless of the type of service your host.

Since I reside in Sri Lanka, SMS-based or Call-based 2FA is unreliable due to frequent connectivity and other ISP issues. Therefore, I recommend using TOTP-based 2FA (like Google Authenticator or Authy) for 2FA verification.

Setting this up is as simple as installing the Google Authenticator PAM module, allowing you to use your favorite 2FA app to generate verification codes.

4. Use Fail2Ban to Block Brute Force Attacks

If you're a sysadmin and not using Fail2Ban, I honestly don't know what to say.

Fail2Ban monitors failed login attempts and blocks repeated attempts, preventing brute-force attacks on your SSH port.

Pro Tip: If you're already using SSH key-based authentication, disable password-based logins entirely.

5. Use Certificate-Based Authentication (mTLS) for SSH

This is a lesser-known but powerful practice I personally follow. By using certificate-based authentication, only trusted devices with valid certificates can even attempt to connect to your SSH server.

I'll be writing a detailed article on this soon, but for now, trust me — it's worth implementing.

6. Regularly Audit and Rotate SSH Keys

Just like with passwords, rotating SSH keys and mutal TLS (mTLS) certificates keeps you one step ahead of targeted attacks.

Your goal isn't just to make attackers give up on you — it's to make them dread targeting anyone else ever again.

🛡️ Live to See Another Day

Thanks for reading! Stay safe out there.