如何在 Netcup 服务器上配置 Ed25519 SSH 密钥、连接多路复用与 OpenSSH 密码学加固

传统的 RSA-2048 与 RSA-4096 密钥基于大整数质因数分解难题，不仅生成的公钥字符串长达 740 余个字符、握手验签消耗更多 CPU 周期，而且密钥体积臃肿；而 ECDSA (ecdsa-sha2-nistp256) 椭圆曲线则因依赖 NIST P-256 常数且一旦操作系统的伪随机数发生器（CSPRNG）出现微小熵偏差就会直接泄露私钥而备受密码学界质疑。相比之下，由密码学家 Daniel J. Bernstein 设计的 Ed25519（基于 Twisted Edwards Curve25519 曲线的数字签名算法）生成的公钥仅 68 个字符，采用确定性 SHA-512 哈希派生签名随机数（免疫 RNG 缺陷），并以恒定时间（Constant-Time）执行点乘运算以防御时序侧信道攻击。

为什么我们在生成 Ed25519 私钥时要特别强调加上 -a 100 参数并设置高强度保护口令（Passphrase）？当您在本地电脑上运行 ssh-keygen 时，生成的私钥文件会以 OpenSSH 专有格式存储在本地磁盘（~/.ssh/id_ed25519_netcup）中，并采用基于 bcrypt_pbkdf 的密钥派生函数（KDF）将您输入的保护口令转换为对称加密密钥。显式指定 -a 100（将默认的 16 轮迭代提升至 100 轮高内存消耗的 bcrypt 哈希计算）会使本地正常解锁私钥仅增加约 0.25 秒的无感耗时，但万一您的笔记本电脑不慎遗失或私钥备份被窃取，攻击者使用 GPU 阵列进行离线字典爆破的算力成本将飙升 6 倍以上！

如果您在安全性要求极高的核心运维工作站上操作，OpenSSH 8.2+ 与 Ubuntu 24.04 内置的 OpenSSH 9.6 还原生支持基于硬件安全芯片的 FIDO2 / U2F 密钥（ssh-keygen -t ed25519-sk -O resident -O verify-required）。使用 YubiKey 5 或 SoloKey 生成 ed25519-sk 密钥后，Curve25519 私钥种子永远封存在硬件安全芯片内部而绝不会出现在电脑硬盘或内存中；每次发起 SSH 连接时都必须由管理员手指物理触摸硬件金手指才能完成签名。

为了提升日常多窗口运维的响应体验，建议在本地工作站的 ~/.ssh/config 中同步开启 OpenSSH 客户端连接多路复用（ControlMaster auto 与 ControlPersist 600）。当您的第一个终端窗口完成与 Netcup 服务器的加密握手后，OpenSSH 会在本地创建一个 Unix 域套接字（~/.ssh/sockets/...）；此后 10 分钟内您新开的任何终端标签页、scp 文件传输、rsync 增量同步或 Ansible 剧本都会直接复用这条已建立的加密 TCP 通道，在 15 毫秒内瞬时打开远程 Shell。请对照下表评估各算法特性并在本地工作站执行下方命令：

# 1. 在您的本地工作站电脑上生成带有 100 轮 bcrypt KDF 保护的 Ed25519 密钥对
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_netcup -C "admin@netcup-prod-2026"

# 2. 在本地工作站配置 ~/.ssh/config，实现别名一键登录与 TCP 连接多路复用
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

使用 ssh-copy-id 工具将刚刚生成的 .pub 公钥自动追加至远程 Netcup 服务器的 ~/.ssh/authorized_keys 文件中（您也可以在 Netcup SCP 控制面板的个人资料或重装向导中预存公钥，让 Cloud-Init 在新机首次启动时自动注入）。验证公钥登录成功后，下一步是配置 /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf Drop-in 加固文件。

在修改 Ubuntu 24.04 或 Debian 12 的 OpenSSH 配置时，必须高度警惕 /etc/ssh/sshd_config.d/ 目录的首次匹配优先生效（First-Match Wins）解析规则。因为主配置文件 /etc/ssh/sshd_config 在文件最开头就执行了 Include /etc/ssh/sshd_config.d/*.conf，如果该目录下存在 Cloud-Init 自动生成的 50-cloud-init.conf（内含 PasswordAuthentication yes），那么按字母序排在后面的 99-netcup-crypto-hardening.conf 或主文件末尾写的 PasswordAuthentication no 将全部被忽略！因此，在部署加固配置时必须同步删除 50-cloud-init.conf，并通过 sudo sshd -T 打印内核运行时真实生效的配置树进行核验。

在密码学套件层面，下方配置将密钥交换算法（KexAlgorithms）强制锁定为 OpenSSH 9.6 原生支持的后量子混合密钥交换算法 sntrup761x25519-sha512@openssh.com 与 curve25519-sha256。sntrup761x25519 将经典椭圆曲线 Diffie-Hellman（X25519）与基于格密码学（Lattice-based）的抗量子算法 Streamlined NTRU Prime (sntrup761) 结合在一起，能够有效防御攻击者当前实施的“先截获加密流量存储、待未来量子计算机问世后再行解密（Harvest Now, Decrypt Later）”威胁。同时，我们将对称加密算法严格限定为 chacha20-poly1305 与 aes256-gcm，并将消息认证码（MACs）限定为 Encrypt-then-MAC (*-etm@openssh.com) 模式。

此外，我们在加固配置中显式加入了 AllowAgentForwarding no。许多开发人员习惯在本地开启 ForwardAgent yes 以便在登录 VPS 后直接拉取 GitHub 私有仓库，但 SSH Agent 转发会在远程服务器的 /tmp/ssh-XXXX/ 目录下创建一个域套接字；一旦该服务器上的任何进程获取了 root 权限，攻击者就能直接劫持该套接字并冒用您的本地密钥横向入侵您的所有其他服务器。如果需要跨跳板机连接或拉取代码，请始终使用安全的 ProxyJump（ssh -J）或只读的仓库级 GitHub Deploy Key：

# 1. 从本地工作站将 Ed25519 公钥安全上传至 Netcup 服务器
ssh-copy-id -i ~/.ssh/id_ed25519_netcup.pub deployadmin@203.0.113.10

# 2. 在 Netcup 服务器上创建 /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 sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
EOF

# 清理 Cloud-Init 遗留的密码登录覆盖文件，检验配置语法并输出最终生效参数
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

虽然将 SSH 从默认的 TCP 22 端口迁移至高位自定义端口（如 2222 或 28422）不能替代 Ed25519 公钥认证（因为针对特定 IP 的全端口扫描器依然能在数秒内扫遍 1–65535 端口），但修改端口在日常运维中具有极高的工程降噪价值：它能直接过滤掉公网上 99% 盲目扫射 22 端口的低级僵尸网络流量，使您的 systemd-journald 系统日志保持高度整洁，并显著降低 Fail2ban 频繁调用 netfilter 封禁 IP 的无谓开销。

从 Ubuntu 22.10 开始引入并在 Ubuntu 24.04 LTS (Noble Numbat) 中全面成为默认标准的架构变更是：OpenSSH 不再由常驻后台的 ssh.service 直接绑定端口，而是改由 systemd 套接字激活（ssh.socket） 按需接管端口监听！在套接字激活模式下，开机时由 PID 1（systemd）负责绑定并监听 TCP 端口，只有当外部客户端发来第一个 TCP SYN 握手包时，systemd 才会按需唤醒 sshd 守护进程。这意味着如果您按照传统教程去修改 /etc/ssh/sshd_config 里的 Port 2222，在 Ubuntu 24.04 上根本不会产生任何效果！

要在 Ubuntu 24.04 LTS 上正确修改 SSH 监听端口，必须创建针对 ssh.socket 的 systemd Drop-in 覆盖文件 /etc/systemd/system/ssh.socket.d/override.conf。在编写 [Socket] 配置块时，必须严格遵循 systemd 的数组重置语法：第一行必须先写一个不带任何值的空 ListenStream=（用于清空 /usr/lib/systemd/system/ssh.socket 中预设的默认 22 端口），紧接着再分两行明确声明 ListenStream=0.0.0.0:2222（IPv4）与 ListenStream=[::]:2222（IPv6）。如果漏写了第一行空赋值，systemd 会将 2222 端口追加在 22 端口之后，导致 22 与 2222 端口同时处于监听状态。

在执行 systemctl daemon-reload 与 systemctl restart ssh.socket 切换端口之前，请务必先在 UFW 以及 Netcup SCP 宿主机防火墙（若已开启）中放行新的 2222/tcp 端口。待 ss -tlpn 确认 systemd 已在 2222 端口正常监听、且您已在新终端窗口通过 ssh -p 2222 deployadmin@203.0.113.10 验证登录无误后，再移除旧的 22 端口防火墙规则：

# 1. 切换端口前，务必先在 UFW（以及 Netcup SCP 防火墙）中放行新的 SSH 端口
sudo ufw allow 2222/tcp comment 'Custom OpenSSH Port'

# 2. 创建针对 ssh.socket 的 systemd 套接字覆盖配置文件
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. 重载 systemd 守护进程配置并重启 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))