SSH连接慢主因是密钥交换与加密算法协商低效，精简KEX算法（如优先curve25519-sha256）、禁用SHA-1类算法、优化ciphers/MACs组合、关闭GSSAPI认证可显著提速。
SSH 远程连接慢，很多时候不是网络卡，而是加密协商环节拖了后腿。密钥交换（KEX）和加密算法协商发生在认证之前，一旦客户端和服务端支持的算法不匹配或效率低，就会反复尝试、超时重试，导致连接卡在“waiting for keys”阶段几秒甚至十几秒。
精简密钥交换算法（KEX）
默认配置通常包含大量老旧、低效或不常用算法（如 diffie-hellman-group1-sha1），服务端需逐个比对兼容性，耗时明显。
- 编辑 /etc/ssh/sshd_config，显式指定高效现代算法：
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
- 优先选 Curve25519：计算快、安全性高、CPU 占用低；
- 禁用 SHA-1 类算法（如 group1/group14-sha1），它们已被标记为弱且协商更慢；
- 重启服务：sudo systemctl restart sshd。
选用轻量级加密与认证算法
加密（ciphers）和消息认证（MACs）直接影响每字节传输的加解密开销，尤其在高吞吐或低配设备上差异显著。
- 推荐组合（兼顾速度与安全）：
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
Macs hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
- ChaCha20-Poly1305 在无 AES-NI 指令集的 CPU（如部分 ARM 或老 Intel）上远快于 AES；
- GCM 和 ETM 模式是 AEAD（认证加密）标准，一次运算完成加密+校验，比传统 CBC+HMAC 更高效；
- 避免使用 3des-cbc、arcfour 等已弃用或性能差的算法。
关闭非必要认证机制
GSSAPI 认证（常用于 Kerberos 域环境）在普通 Linux 服务器上基本用不到，但它默认开启，会触发额外的票据查询和协议协商，单次连接可能多耗 1–3 秒。
- 在 /etc/ssh/sshd_config 中设置：
GSSAPIAuthentication no
GSSAPICleanupCredentials no
- 客户端也可临时禁用：ssh -o GSSAPIAuthentication=no user@host；
- 若确认未接入域控环境，彻底关闭可立竿见影。
启用压缩（仅限低带宽/高延迟链路）
加密本身不压缩数据，而 SSH 支持通道级压缩。它不能加速密钥交换，但能减少后续命令输出、日志回传等载荷体积，间接缓解高延迟下的感知卡顿。
- 服务端启用（谨慎）：Compression yes（注意：对已压缩内容如图片、视频无效，且增加 CPU 负担）；
- 更推荐客户端按需启用：ssh -C user@host，或在 ~/.ssh/config 中为特定主机添加 Compression yes；
- 适用于跨国、移动网络、卫星链路等带宽受限场景，局域网或千兆直连无需开启。
