SSH安全加固实战：快速禁用弱加密算法与配置详解

1. 项目概述：为什么SSH安全加固刻不容缓

最近在排查几台线上服务器的安全基线时，我发现了一个普遍存在但极易被忽视的风险点：SSH服务默认启用了大量已被证实存在安全缺陷的弱加密算法。这可不是危言耸听，想象一下，你服务器的“大门”（SSH端口）虽然上了锁，但用的却是那种老旧的、能被特定工具轻易撬开的锁芯（弱算法）。攻击者不需要知道你的密码，他们可以利用这些算法本身的漏洞，或者通过降级攻击，迫使你的SSH客户端和服务端使用不安全的加密方式进行通信，从而可能实现中间人攻击甚至直接解密流量。这绝不是理论风险，在各类安全攻防演练和真实攻击事件中，利用弱SSH算法是攻击队打开内网突破口的常见手段。

因此，对SSH服务进行安全加固，特别是快速禁用那些已知的弱加密算法，就成了每一位服务器管理员、运维工程师乃至开发者的必备技能。这不仅仅是安全合规的要求，更是保护业务数据资产的第一道实用防线。本文将围绕sshd_config这个核心配置文件，带你彻底弄懂SSH加密算法的安全门道，并提供一个清晰、可立即上手的加固操作指南。无论你是管理着一台云主机，还是维护着一个庞大的服务器集群，这套方法都能让你的SSH服务安全性提升一个显著的等级。

2. SSH安全加固的核心思路与算法选型

2.1 理解SSH连接中的算法“握手”

在深入配置之前，我们必须先理解SSH连接建立时，客户端和服务器端是如何协商使用哪些算法的。这个过程就像两个人在见面打招呼前，先约定好用哪种语言和暗号交流。SSH协议主要涉及四种类型的算法协商：

1. 密钥交换算法 (KexAlgorithms)：用于在不可信的网络中安全地生成一个双方共享的会话密钥。这个密钥将用于后续对称加密的初始化。弱密钥交换算法可能导致会话密钥被破解。
2. 主机密钥算法 (HostKeyAlgorithms)：服务器向客户端证明自己身份时使用的非对称密钥算法。客户端依靠此算法验证服务器是否是其想要连接的那一台，防止中间人攻击。
3. 加密算法 (Ciphers)：用于对传输的会话数据进行对称加密，确保数据的机密性。弱加密算法可能被直接破解或通过旁路攻击泄露信息。
4. 消息认证码算法 (MACs)：用于验证传输数据的完整性，确保数据在传输过程中未被篡改。弱MAC算法可能导致数据被伪造。

sshd_config文件中的相关配置指令，正是用来限定服务器端在这四个类别中“愿意”接受哪些算法。我们的加固目标，就是移除“弱算法”，只保留“强算法”。

2.2 如何界定“弱”算法与“强”算法？

那么，哪些算法是“弱”的呢？这并没有一个永恒不变的清单，但随着密码学研究和计算能力的进步，一些过去安全的算法会逐渐变得不安全。通常，安全社区和各类标准（如NIST、PCI DSS等）会给出指导。目前普遍认为需要禁用的弱算法包括：

• 密钥交换算法：diffie-hellman-group1-sha1,diffie-hellman-group14-sha1。SHA-1哈希函数已存在碰撞漏洞，基于此的密钥交换安全性不足。
• 加密算法：
  • CBC模式算法：如aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc等。CBC模式容易受到填充预言攻击（如Lucky13）。
  • 弱流加密算法：arcfour,arcfour128,arcfour256。RC4算法存在严重偏见，已被证明不安全。
  • 其他过时算法：blowfish-cbc,cast128-cbc等。
• 消息认证码算法：所有基于SHA-1的MAC算法，如hmac-sha1,hmac-sha1-96。同样因为SHA-1的脆弱性。
• 主机密钥算法：ssh-dss(DSA)。DSA密钥长度通常限制在1024位，强度不足，且对随机数生成非常敏感，实践中已不推荐使用。ssh-rsa（使用SHA-1签名）在某些严格策略下也被视为弱算法，建议优先使用rsa-sha2-256或rsa-sha2-512。

强算法的选择：现代、安全的SSH连接应优先使用：

• 密钥交换：curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256。
• 加密：chacha20-poly1305@openssh.com（在移动设备上性能尤佳）,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr。CTR和GCM模式避免了CBC模式的安全问题。
• MACs：umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com。注意-etm（Encrypt-then-MAC）模式比传统的MAC-then-Encrypt更安全。
• 主机密钥：ssh-ed25519,rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256。

注意：禁用算法时，务必确保至少保留一个客户端支持的算法，否则会导致连接失败。在生产环境操作前，务必在测试环境验证。

2.3 方案选型：升级OpenSSH vs 修改配置

面对弱算法问题，通常有两种主流思路，这也是网络资料中常提到的：

1. 方案一：升级OpenSSH至最新版本。新版本的OpenSSH通常默认已禁用已知的弱算法，安全性最好。这是最根本、最推荐的解决方案。
2. 方案二：修改sshd_config配置文件，显式指定允许的算法。在不便升级或需要精细化控制的场景下，这是最直接、最快速的方法。

为什么本文聚焦方案二？因为升级操作涉及包管理、依赖、兼容性和重启服务，在大型或稳定性要求极高的生产环境中，可能存在窗口期和风险。而修改配置并重载服务，影响范围小、回滚快，是进行“热加固”的黄金手段。掌握了方案二，你就能在任何版本的OpenSSH上实施快速安全加固。当然，两者并不互斥，长期来看，升级仍是必由之路。

3. 实战：逐行详解sshd_config安全加固配置

现在，我们进入实战环节。请打开你的服务器上的/etc/ssh/sshd_config文件。在修改前，强烈建议先备份：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak。

我们将通过添加或修改以下几行关键配置，来禁用弱算法。请注意，配置项是大小写敏感的。

3.1 禁用弱密钥交换算法 (KexAlgorithms)

找到或添加以下行：

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256

• 作用：这条指令限定了服务器端允许的密钥交换算法列表。我们列出了当前推荐的所有强算法。
• 实操要点：diffie-hellman-group-exchange-sha256兼容性较好，但性能开销相对椭圆曲线算法（curve25519-*,ecdh-*）更大。椭圆曲线算法更安全、更高效，应优先排列在前。如果你的客户端非常老旧（如一些嵌入式设备），可能需要保留diffie-hellman-group14-sha256以兼容，但务必移除-sha1的版本。

3.2 禁用弱加密算法 (Ciphers)

找到或添加以下行：

Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr

• 作用：指定允许使用的对称加密算法。这里我们禁用了所有-cbc模式的算法和arcfour*。
• 原理解读：chacha20-poly1305是一种流加密结合认证加密的模式，在现代CPU上性能优异，尤其适合移动设备。aes-gcm是带认证的AES分组加密模式，既保证了机密性也保证了完整性。aes-ctr是AES的计数器模式，相比CBC更安全。排列顺序代表了服务器的偏好顺序，客户端会从列表中选择第一个它支持的算法。

3.3 禁用弱消息认证码算法 (MACs)

找到或添加以下行：

MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

• 作用：指定允许使用的消息完整性校验算法。关键点在于全部使用了-etm模式。
• 避坑指南：绝对不要使用不带-etm的MAC算法（如hmac-sha2-256）。传统的MAC-then-Encrypt模式存在理论上的弱点，而Encrypt-then-MAC (-etm) 被证明是更安全的构造方式。OpenSSH 6.2及以上版本支持-etm模式。

3.4 强化主机密钥算法 (HostKeyAlgorithms)

找到或添加以下行：

HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256

• 作用：指定服务器用于证明自身身份的公钥算法优先级。ssh-ed25519是EdDSA算法，密钥短、性能高、安全性好，是当前首选。
• 重要提醒：如果你禁用了ssh-rsa（即传统的RSA签名使用SHA-1），请确保你的服务器主机密钥对中包含了其他类型的密钥（如ed25519或ecdsa），并且客户端的known_hosts文件中有对应的新主机密钥记录。否则，客户端在连接时会因找不到可信任的主机密钥而报错。通常，新安装的OpenSSH服务器会默认生成多种类型的密钥对。

3.5 一个完整的安全配置片段示例

你可以将上述配置整合到sshd_config文件的末尾，或者替换原有的对应配置行。一个加固后的配置片段看起来是这样的：

# 禁用弱算法，启用强算法 KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256 # 其他推荐的安全配置（可选但强烈建议） Protocol 2 # 只使用SSH协议第2版，禁用不安全的SSH1 PermitRootLogin prohibit-password # 禁止root用户直接使用密码登录，建议改为`no`或使用密钥登录 PasswordAuthentication no # 禁用密码认证，强制使用密钥认证（根据实际情况调整） MaxAuthTries 3 # 限制每次连接的最大认证尝试次数 ClientAliveInterval 300 # 客户端活跃检测间隔（秒） ClientAliveCountMax 2 # 客户端无响应断开前的检测次数

4. 配置验证与生效全流程

配置修改完成后，绝对不能直接重启sshd服务，万一配置有误导致服务无法启动，你可能就失去服务器的访问权限了。请严格按照以下流程操作：

4.1 第一步：语法检查

使用sshd命令的-t参数测试配置文件语法是否正确。

sudo sshd -t

如果没有任何输出，表示语法正确。如果出现错误，它会明确指出哪一行有问题，根据提示修正即可。

4.2 第二步：模拟连接测试（关键步骤）

这是防止自己“被关在门外”的最重要一步。我们需要在不重启服务的情况下，模拟新配置下的连接过程。

1. 在服务器上启动一个临时sshd进程，监听一个非标准端口（例如 2222），并使用我们刚修改的配置文件：

   sudo /usr/sbin/sshd -d -p 2222 -f /etc/ssh/sshd_config

   -d表示调试模式，会在前台输出详细信息；-p 2222指定监听端口；-f指定配置文件。

2. 从另一台机器（客户端）尝试连接：

   ssh -p 2222 -oCiphers=aes128-ctr -oKexAlgorithms=ecdh-sha2-nistp256 user@your_server_ip

   这个命令指定了端口和具体的算法，用于测试新配置是否接受指定的强算法。你应该能成功连接。

3. 测试弱算法是否被拒绝：

   ssh -p 2222 -oCiphers=3des-cbc user@your_server_ip

   这个命令故意指定一个已被禁用的弱加密算法（3des-cbc）。连接应该失败，并返回类似no matching cipher found的错误。这表明我们的加固生效了！

4. 测试完成后，在服务器上按Ctrl+C终止临时sshd进程。

4.3 第三步：正式生效与监控

1. 重载SSH服务：如果测试全部通过，就可以安全地让新配置生效了。通常使用systemctl重载服务：

   sudo systemctl reload sshd # 对于Systemd系统（如Ubuntu 16.04+, CentOS 7+） # 或者 sudo service ssh reload # 对于SysVinit系统

   reload命令会让sshd主进程重新读取配置文件，而不会断开现有的连接，这对生产环境非常友好。

2. 验证运行中服务的配置：重载后，可以通过检查sshd主进程的参数来确认它是否加载了新配置：

   ps aux | grep sshd | grep -v grep

   查看输出的命令中是否包含你的配置文件路径。

3. 建立新的SSH连接：从客户端新建一个SSH连接，使用-vvv参数查看详细的算法协商过程，确认连接使用的是我们指定的强算法。

   ssh -vvv user@your_server_ip

   在输出信息中，搜索kex: algorithm,cipher:,mac:等关键词，可以看到实际协商使用的算法。

5. 常见问题排查与修复实录

在实际操作中，你可能会遇到以下问题。这里记录了我踩过的坑和解决方法。

5.1 问题：配置后SSH连接失败，提示“no matching key exchange/cipher/mac algorithm found”

这是最常见的问题，意味着客户端提供的所有算法都被服务器端拒绝了。

• 排查思路：

  1. 检查客户端版本：使用ssh -V查看客户端OpenSSH版本。非常老的客户端（如OpenSSH 5.x）可能不支持curve25519或chacha20-poly1305。
  2. 检查服务器配置：确认sshd_config中KexAlgorithms,Ciphers,MACs的拼写是否正确，是否有多余的空格或逗号。
  3. 使用兼容性算法列表：如果客户端较老，需要在服务器配置中添加一些兼容性更强的算法，但务必放在列表最后作为备选。例如：

     Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes256-cbc

     注意：这里仅作示例，aes128-cbc是弱算法，仅在万不得已需要兼容老旧客户端时临时添加，并应尽快推动客户端升级。

• 修复步骤：

  1. 在测试环境中，逐步放宽服务器端的算法列表，每次添加一个可能客户端支持的算法，直到连接成功，从而定位出客户端实际支持的算法。
  2. 根据定位结果，更新服务器配置，在安全性和兼容性之间取得平衡。
  3. 制定计划，升级老旧客户端。

5.2 问题：连接时出现“Host key verification failed”警告

这通常是因为修改HostKeyAlgorithms后，客户端尝试使用新的算法（如rsa-sha2-256）验证服务器主机密钥，但客户端本地~/.ssh/known_hosts文件中记录的是旧格式的密钥指纹。

• 解决方法：
  1. 最安全的方法：在客户端使用ssh-keygen -R your_server_ip删除旧的主机密钥记录。下次连接时，会重新获取并信任新的主机密钥。
  2. 或者，在客户端连接时暂时忽略主机密钥检查（仅用于测试）：ssh -o StrictHostKeyChecking=no ...，生产环境不推荐。

5.3 问题：服务重载失败，systemctl status sshd显示错误

• 排查：首先运行sudo sshd -t检查语法。如果语法正确，查看系统日志获取详细信息：sudo journalctl -u sshd -xe --no-pager | tail -50。
• 常见原因：
  • 配置指令拼写错误。
  • 指定的算法在当前OpenSSH版本中不支持。可以用ssh -Q kex（查询支持的密钥交换算法）、ssh -Q cipher、ssh -Q mac命令在服务器上查看当前OpenSSH支持的所有算法。
  • 配置中使用了冲突的参数。

5.4 问题：如何批量对多台服务器进行加固？

对于运维大批量服务器的场景，手动登录每台机器修改效率太低且易出错。

• 推荐方案：使用配置管理工具，如 Ansible。
• Ansible Playbook 示例片段：

  - name: Harden SSH configuration hosts: all_servers become: yes tasks: - name: Backup original sshd_config copy: src: /etc/ssh/sshd_config dest: /etc/ssh/sshd_config.bak-{{ ansible_date_time.date }} remote_src: yes owner: root group: root mode: '0600' - name: Set strong SSH algorithms lineinfile: path: /etc/ssh/sshd_config regexp: "^{{ item.key }}\\s" line: "{{ item.key }} {{ item.value }}" state: present with_items: - { key: 'KexAlgorithms', value: 'curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256' } - { key: 'Ciphers', value: 'chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr' } - { key: 'MACs', value: 'umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com' } - { key: 'HostKeyAlgorithms', value: 'ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256' } - name: Test sshd configuration command: sshd -t changed_when: false failed_when: false register: sshd_test - name: Reload sshd if config is OK systemd: name: sshd state: reloaded when: sshd_test.rc == 0 - name: Fail if config test failed fail: msg: "sshd config test failed. Please check /etc/ssh/sshd_config on {{ inventory_hostname }}" when: sshd_test.rc != 0

  这个Playbook会先备份，然后设置强算法，测试语法，最后重载服务。通过这种方式，可以安全、一致地完成大规模加固。

6. 加固效果验证与持续监控

配置生效后，如何验证加固效果呢？除了前面提到的连接测试，还有一些专业工具和方法。

6.1 使用扫描工具进行审计

使用专门的SSH安全扫描工具，从外部视角检查你的服务器。

• ssh-audit：这是一个非常流行的Python工具。

  # 安装 pip install ssh-audit # 扫描你的服务器 ssh-audit your_server_ip

  它会输出一份详细的报告，列出服务器支持的算法、密钥信息，并标记出其中的弱算法、不安全的配置，以及给出改进建议。加固后再次扫描，应该看到所有“fail”或“warning”的项都被清除了。

• Nmap NSE脚本：Nmap也提供了SSH相关的审计脚本。

  nmap -p 22 --script ssh2-enum-algos,ssh-hostkey,ssh-auth-methods your_server_ip

  ssh2-enum-algos脚本会枚举出服务器支持的所有算法。

6.2 监控与持续改进

安全加固不是一劳永逸的。密码学在进步，新的漏洞也可能被发现。

1. 订阅安全公告：关注OpenSSH官方发布的安全公告。
2. 定期扫描：将ssh-audit扫描纳入日常或周期性的安全巡检流程。
3. 关注算法演进：例如，随着量子计算的发展，现有的RSA、ECC算法在未来可能面临威胁，后量子密码学算法会逐渐被引入。保持对行业动态的关注。
4. 统一配置管理：确保所有新上线的服务器都应用了同样的安全SSH配置基线。

最后，我个人在多次生产环境加固中最大的体会是：测试，测试，再测试。尤其是在通过自动化工具批量修改前，一定要在少数几台代表性机器上（不同OS版本、不同OpenSSH版本）进行完整的测试，包括语法检查、模拟连接、工具扫描，并观察一段时间确保业务连接无异常。安全与稳定性永远是运维天平的两端，而充分的测试是找到最佳平衡点的唯一途径。