ssh默认端到端加密，关键在于确保链路不被降级或绕过：需强制强加密算法（如chacha20-poly1305）、明确转发类型覆盖范围、禁用allowtcpforwarding等高危选项，并限制用户与ip访问。
确认实际协商的是强加密算法
OpenSSH 默认启用 AES-GCM、ChaCha20-Poly1305 等现代算法，但老旧服务端可能仍开放 RSA-SHA1、CBC 模式等弱套件。必须主动收紧：
- 服务端（/etc/ssh/sshd_config）强制指定：
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com<br>KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256
- 客户端（~/.ssh/config）可按目标主机单独锁定：
Host prod-server<br> Ciphers chacha20-poly1305@openssh.com<br> KexAlgorithms curve25519-sha256
- 连接后执行
ssh -v user@host，检查日志中 debug1: kex: algorithm: 和 debug1: ciphers: 行，确认实际生效的是你指定的强算法，而非回退到 weak cipher
明确转发类型与加密覆盖范围
SSH 加密只保护「本地 SSH 客户端 ↔ 远程 SSH 服务端」这一跳。若目标服务在第三台机器上，后续一跳是否加密，不由 SSH 决定：
-
本地转发（-L）：如
ssh -L 8080:10.0.2.10:80 jump-host，本机→jump-host 加密，jump-host→10.0.2.10 是明文——除非 Web 服务本身启用了 HTTPS - 远程转发（-R）：流量从远程端口进入，经 SSH 解密后才发往本地服务，加密段仍是客户端↔服务端，本地服务自身无加密保障
- 动态转发（-D）：建立 SOCKS5 代理，所有走该代理的应用流量全程加密传至 SSH 服务端，再由服务端代为发起外网请求——这是唯一能让浏览器、curl 等任意应用流量实现端到端加密的常用方式
关闭高危功能，堵住隧道逃逸口
默认开启的某些选项，会让 SSH 隧道变成攻击跳板或信息泄露通道：
- 服务端禁用端口转发（除非业务必需）：
AllowTcpForwarding no - 禁止远程监听绑定到公网地址：
GatewayPorts no（默认值，切勿改为 yes） - 客户端启用主机密钥严格校验：
StrictHostKeyChecking yes（默认），首次连接务必人工核对 fingerprint，防止中间人替换服务端 - 禁用空密码和密码登录：
PasswordAuthentication no+PermitEmptyPasswords no，只留密钥认证一条可信路径
限制访问源头，压缩攻击面
即使加密再强，如果谁都连得上，也白搭：
- 仅允许可信用户登录：
AllowUsers deploy admin - 限制登录 IP 范围（配合防火墙更佳）：
Match Address 192.168.10.0/24<br> AllowUsers admin
- 改用非标准端口（如 2222），虽非加密手段，但能过滤掉 90% 的自动化扫描，让真实攻击更容易被日志识别
- 搭配 Fail2ban 监控 /var/log/auth.log，对连续失败认证的 IP 自动封禁
