在网络带宽受限但 CPU 资源充足的情况下，开启 Compression 能有效减少传输数据量；而在高带宽或 CPU 敏感场景下，选择支持硬件加速的 Cipher 算法更能降低加密开销。

第一步：检查版本兼容性

修改配置前，务必确认 OpenSSH 版本，避免配置无效或服务启动失败。

ssh -V

若版本高于 7.4（大多数现代 Linux 发行版），/etc/ssh/sshd_config 中不再支持 Compression 指令，强行添加会导致 sshd 服务重启失败。建议仅在客户端配置压缩。

第二步：分场景配置实操

1. 客户端配置（推荐）

修改本地 ~/.ssh/config，适用于所有版本，风险较低：

Host *
    Compression yes
    Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr

2. 服务端配置（旧版本仅限）

若确认服务端 OpenSSH 版本低于 7.4，可修改 /etc/ssh/sshd_config：

# 仅旧版本支持，新版本请注释掉此行
# Compression yes
Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr

修改后重载服务（保留当前会话以防断开）：

sudo systemctl reload sshd

第三步：量化验证速度

使用 time 命令配合 scp 进行基准测试，对比优化前后的传输耗时。

1. 测试未优化耗时：

time scp large_file.log user@hostname:/tmp/

2. 测试优化后耗时（开启压缩）：

time scp -C large_file.log user@hostname:/tmp/

3. 观察资源占用：

在服务端使用 top -H -p $(pgrep -f sshd) 观察 sshd 线程 CPU 占用。若开启压缩后 CPU 飙升但耗时未减，说明数据本身已压缩（如视频、zip），应关闭压缩。

常见风险与排查

• 服务启动失败：若修改服务端配置后 sshd 无法启动，立即通过控制台检查 /var/log/auth.log 或 journalctl -u sshd，通常是因为使用了废弃的 Compression 指令。
• 握手失败：出现 no matching cipher found 说明两端算法不匹配，需确保客户端与服务端 Ciphers 列表有交集。
• 安全风险：避免使用 arcfour 或 3des 等弱加密算法，即使它们速度较快。
• 连接保护：修改服务端配置前，务必保留一个已连接的会话窗口，直到确认新连接正常后再关闭，防止配置错误导致无法远程登录。

参考来源

• OpenSSH Portable, "sshd_config - OpenSSH SSH daemon configuration file", man page.
• OpenSSH Portable, "ssh - OpenSSH SSH client (remote login program)", man page.