How to Set Up Ed25519 SSH Keys, Multiplexing & OpenSSH Hardening on Netcup

Legacy RSA-2048 and RSA-4096 keys rely on integer factorization, producing bulky ~740-character public keys with slower signature verification, while ECDSA (ecdsa-sha2-nistp256) relies on NIST P-256 curve constants and is vulnerable to private-key recovery if the host CSPRNG ever produces a biased signature nonce k. By contrast, Ed25519 (ssh-ed25519, based on Daniel J. Bernstein’s Twisted Edwards Curve25519) produces compact 68-character public keys, computes signatures deterministically via SHA-512 without requiring random per-signature nonces, and executes in constant CPU cycles to defeat timing side-channel attacks.

When generating an Ed25519 key pair on your workstation, always pass the -a 100 flag alongside a strong passphrase. OpenSSH stores private keys in its native OPENSSH PRIVATE KEY format encrypted via the bcrypt_pbkdf key derivation function. Increasing the KDF rounds from the default (16) to 100 deliberately adds ~250 milliseconds of CPU work when unlocking your private key locally—a delay that is imperceptible to a human administrator but slows down offline GPU dictionary attacks against a stolen laptop backup by a factor of 6×.

For high-security administrative workstations, OpenSSH 8.2+ and Ubuntu 24.04’s OpenSSH 9.6 also support hardware-bound FIDO2 / U2F security keys (ssh-keygen -t ed25519-sk -O resident -O verify-required). With an ed25519-sk key stored on a YubiKey 5 or Token2 security key, the raw Curve25519 private key material never touches your laptop’s NVMe drive or RAM; every SSH handshake requires a physical capacitive touch on the hardware token.

To make daily multi-tab server administration effortless, pair your Ed25519 key with OpenSSH client connection multiplexing (ControlMaster auto and ControlPersist 600) inside your local ~/.ssh/config. Once your first ssh nc-prod session completes the Curve25519 key exchange and unlocks your passphrase, OpenSSH opens a local Unix domain socket (~/.ssh/sockets/...). Any subsequent terminal tabs, scp transfers, rsync runs, or Ansible playbooks opened within the next 10 minutes piggyback over that existing encrypted TCP connection—opening new remote shells in under 15 milliseconds:

# 1. Generate an Ed25519 key pair with 100 bcrypt KDF rounds on your local computer
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_netcup -C "admin@netcup-prod-2026"

# 2. Configure ~/.ssh/config on your workstation for 1-word login & TCP multiplexing
mkdir -p ~/.ssh/sockets && chmod 0700 ~/.ssh ~/.ssh/sockets
cat << 'EOF' >> ~/.ssh/config
Host nc-prod
    HostName 203.0.113.10
    User deployadmin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_netcup
    IdentitiesOnly yes
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600
    ServerAliveInterval 60
EOF
chmod 0600 ~/.ssh/config

Generating public/private ed25519 key pair.
Your identification has been saved in /home/user/.ssh/id_ed25519_netcup
Your public key has been saved in /home/user/.ssh/id_ed25519_netcup.pub

Once your public key is generated, deploy it to your unprivileged sudo user (deployadmin) using ssh-copy-id, which automatically creates ~/.ssh (0700) and appends your public key to ~/.ssh/authorized_keys (0600). You can also pre-register your Ed25519 public key inside the Netcup Server Control Panel (SCP → Profile / SSH Keys) so that any future Ubuntu 24.04 or Debian 12 image you provision injects your key automatically during Cloud-Init first boot.

Before editing OpenSSH server configuration on Ubuntu 24.04 or Debian 12, understand how OpenSSH evaluates drop-in files. Near the top of the main /etc/ssh/sshd_config file sits the directive Include /etc/ssh/sshd_config.d/*.conf. Because OpenSSH uses a strict first-match-wins parser, any setting defined inside an early drop-in file—most notably /etc/ssh/sshd_config.d/50-cloud-init.conf, which often contains PasswordAuthentication yes—takes precedence over settings written further down in /etc/ssh/sshd_config! Always remove 50-cloud-init.conf (or rename your hardening drop-in 00-netcup-crypto-hardening.conf and verify with sudo sshd -T) so no stale Cloud-Init rule leaves password login enabled.

Beyond disabling passwords (PasswordAuthentication no, KbdInteractiveAuthentication no, AuthenticationMethods publickey), our drop-in config below restricts the cryptographic primitives negotiated during the SSH transport layer handshake. Enabling [email protected] pairs classic X25519 ECDH with the post-quantum lattice-based Streamlined NTRU Prime (sntrup761) algorithm, protecting your administrative sessions against "harvest-now, decrypt-later" quantum traffic recording. Similarly, restricting Ciphers to [email protected] and [email protected] and MACs to Encrypt-then-MAC (*[email protected]) eliminates legacy CBC/SHA-1 weaknesses.

Notice that our configuration also enforces AllowAgentForwarding no. While developers sometimes enable ForwardAgent yes to use their local SSH keys from a remote server (for example, to pull from a private GitHub repository), agent forwarding exposes a Unix domain socket (/tmp/ssh-XXXX/agent.XXXX) inside the remote server. Anyone with root privileges on that machine can hijack the socket and authenticate to every other server your local ssh-agent holds keys for. Instead, use ProxyJump (ssh -J bastion target) or repository-scoped GitHub Deploy Keys:

# 1. Copy public key from your workstation to your Netcup server
ssh-copy-id -i ~/.ssh/id_ed25519_netcup.pub [email protected]

# 2. On the Netcup server, create /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf
cat << 'EOF' | sudo tee /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deployadmin
X11Forwarding no
AllowAgentForwarding no
KexAlgorithms [email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
EOF

# Remove any Cloud-Init password override, validate syntax, and inspect effective settings
sudo rm -f /etc/ssh/sshd_config.d/50-cloud-init.conf
sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods)"

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
authenticationmethods publickey

Moving OpenSSH from TCP port 22 to a high non-standard port (such as 2222 or 28422) is not a substitute for Ed25519 key authentication, because dedicated port scanners (masscan, zmap) can sweep all 65,535 TCP ports of an IPv4 address in seconds. However, changing the SSH port still provides a major operational benefit: it eliminates 99% of opportunistic commodity botnet noise on port 22, keeping your systemd-journald logs clean and reducing unnecessary Fail2ban firewall churn.

Beginning with Ubuntu 22.10 and standardized across Ubuntu 24.04 LTS (Noble Numbat), Canonical migrated openssh-server from a classic standalone daemon (ssh.service) to systemd socket-based activation (ssh.socket). Under socket activation, PID 1 (systemd) binds the TCP port at boot and only spawns sshd when an inbound TCP SYN packet arrives. Consequently, simply editing Port 2222 inside /etc/ssh/sshd_config has zero effect on Ubuntu 24.04—systemd will continue listening on port 22!

To properly change the SSH listening port on Ubuntu 24.04 LTS, you must create a systemd drop-in override at /etc/systemd/system/ssh.socket.d/override.conf. Inside the [Socket] unit section, systemd treats ListenStream as an additive array list. If you only write ListenStream=2222 without first writing an empty ListenStream= reset line, systemd will bind both port 22 and port 2222. Placing an empty ListenStream= line first clears the vendor default port 22 assignment before registering your dual-stack IPv4 (0.0.0.0:2222) and IPv6 ([::]:2222) sockets.

Before reloading systemd and restarting ssh.socket, always open your new port (2222/tcp) in both UFW and the Netcup SCP Hypervisor Firewall (if active). Once ss -tlpn confirms that systemd is listening on port 2222 and you have verified login over the new port (ssh -p 2222 [email protected]), you can safely delete the old port 22 rule (sudo ufw delete allow 22/tcp):

# 1. Allow the new SSH port in UFW (and in Netcup SCP Firewall!) BEFORE switching
sudo ufw allow 2222/tcp comment 'Custom OpenSSH Port'

# 2. Create systemd socket override for ssh.socket
sudo mkdir -p /etc/systemd/system/ssh.socket.d
cat << 'EOF' | sudo tee /etc/systemd/system/ssh.socket.d/override.conf
[Socket]
ListenStream=
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
EOF

# 3. Reload systemd and restart ssh.socket
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tlpn | grep 2222

LISTEN 0      4096         0.0.0.0:2222       0.0.0.0:*    users:(("systemd",pid=1,fd=98))