Strengthening SSH 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.

Walkthrough: Creating SSH Keys with Ed25519

1. Generate Ed25519 Key Pair

Open your terminal and run:

ssh-keygen -t ed25519 -C "[email protected]"

Save the key either with the default or an easy identifible name:

Enter file in which to save the key (/home/user/.ssh/id_ed25519): SH-031_traffagel-server

You'll then be asked for a passphrase. Use one! It protects the private key even if the file is lost or stolen. And please follow a basic password policy even if it is for your LAN servers.

2. Copy your public key to the target server

Again there are many ways to do this, but the most secure way is to use ssh-copy-id (if you are on linux or WSL):

ssh-copy-id -i ~/.ssh/SH-031_traffagel-server user@server

Or you could also copy it manually and paste it into ~/.ssh/authorized_keys on the target server

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. You can do this by editing the etc/ssh/sshd_config and change the line Port 22 to Port 4022. You can use sudo systemctl restart sshd to restart the SSH service. While this doesn't prevent an attack it helps reduces automated bots and script kiddies scanning your ip to discover services.

🔥 Pro Tip: Make all the configuration changes you require carefully and restart the SSH Service in one go

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.

sudo apt install libpam-google-authenticator
nano /etc/pam.d/sshd

Then enable auth required pam_google_authenticator.so

And in /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes

🔥 Pro Tip: For production systems, test from another terminal before disconnecting your current session.

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.

sudo apt install fail2ban

then create or edit ssh jail /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 4022 # define your nodified SSH port here for Fail2Ban to work properly
filter = sshd
logpath = /var/log/auth.log
maxretry = 5

Restart the service:

sudo systemctl restart fail2ban

🔥 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, espcially on production systems. By using certificate-based authentication, only connections with valid certificates can even attempt to connect to your SSH server.

More on this in a this article here.

🔥 Pro Tip: Have a secure location and a fail-safe backup of all your keys and certificates.

6. Regularly Audit and Rotate SSH Keys

Just like with passwords, rotating SSH keys as well as 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.