大批量服务器加固 SSH 最稳妥的方式是用 Ansible 分批灰度执行，先在少数机器验证 playbook 无误，再全量推送，同时必须保留应急登录通道。

准备 Inventory 分组

不要把所有机器放在一个组里全量跑。按业务或机房分组，便于分批执行。创建 hosts.ini 文件：

[web_batch_01]
192.168.1.10
192.168.1.11

[web_batch_02]
192.168.1.12
192.168.1.13

[all:vars]
ansible_user=root
ansible_ssh_private_key_file=~/.ssh/id_rsa

SSH 加固 Playbook 完整示例

以下 ssh_hardening.yml 包含备份、修改、语法检查、服务重启及失败回滚逻辑。请根据实际环境调整参数。

---
- name: SSH Hardening
  hosts: all
  gather_facts: yes
  tasks:
    - name: Set backup file path with timestamp
      set_fact:
        backup_path: "/etc/ssh/sshd_config.bak.{{ ansible_date_time.iso8601_basic_short }}"

    - name: Backup original sshd_config
      copy:
        src: /etc/ssh/sshd_config
        dest: "{{ backup_path }}"
        remote_src: yes
        mode: '0600'

    - name: Apply SSH hardening configurations
      block:
        - name: Disable root login and password auth
          lineinfile:
            path: /etc/ssh/sshd_config
            regexp: "^#?PermitRootLogin"
            line: "PermitRootLogin no"
            backup: yes

        - name: Disable password authentication
          lineinfile:
            path: /etc/ssh/sshd_config
            regexp: "^#?PasswordAuthentication"
            line: "PasswordAuthentication no"
            backup: yes

        - name: Check sshd config syntax
          command: sshd -t
          changed_when: false
          register: sshd_check
          failed_when: sshd_check.rc != 0

        - name: Restart sshd service
          service:
            name: sshd
            state: restarted
      rescue:
        - name: Rollback config on failure
          copy:
            src: "{{ backup_path }}"
            dest: /etc/ssh/sshd_config
            remote_src: yes
            mode: '0600'

        - name: Restart sshd after rollback
          service:
            name: sshd
            state: restarted

        - name: Report failure
          fail:
            msg: "SSH hardening failed, config rolled back. Check {{ backup_path }}"

关键 SSH 配置参数详解

以下是推荐的生产环境加固参数，请根据业务需求调整：

• PermitRootLogin no：禁止 root 直接登录，强制使用普通用户 sudo。
• PasswordAuthentication no：禁用密码登录，强制使用 SSH 密钥对。
• X11Forwarding no：禁用 X11 转发，减少攻击面。
• MaxAuthTries 3：限制最大认证尝试次数，防止暴力破解。
• ClientAliveInterval 300：设置心跳间隔，自动断开空闲连接。

执行命令与灰度策略

执行前务必加上检查参数，不要直接跑：

ansible-playbook -i hosts.ini ssh_hardening.yml `--check` `--diff`

确认无误后再去掉 `--check` 正式执行，建议配合 `--limit` 参数分批：

ansible-playbook -i hosts.ini ssh_hardening.yml `--limit` web_batch_01

怎么验证是否生效

执行完 playbook 后，不要立刻关闭当前窗口。新开一个终端尝试用新策略登录，比如禁用密码后尝试密钥登录。

• 服务端检查：运行 sshd -t 检查配置语法是否有报错，查看 /var/log/secure 或 /var/log/auth.log 确认没有异常认证失败记录。
• 客户端检查：使用 ssh -v user@host 连接，观察 debug 输出中认证方式是否符合预期，比如是否只显示了 publickey。
• 回滚验证：故意在 playbook 中写错一个参数，执行后确认是否触发 rescue 块并恢复原配置。

常见坑与风险排查

• 把自己锁在门外：修改 PermitRootLogin 或 PasswordAuthentication 前，确认当前会话使用的登录方式不会被新配置禁止。确保密钥已授权。
• 配置语法错误：不同版本 OpenSSH 支持的参数略有差异，批量执行前要在不同版本的系统上测试 playbook。使用 sshd -t 是必须的步骤。
• 服务重启失败：如果 sshd 启动失败，自动化脚本可能会卡住或断开。上述 Playbook 中的 block/rescue 机制确保失败时自动恢复备份配置。
• 网络波动导致中断：大批量执行时网络不稳定可能导致部分机器配置一半。建议开启 ansible 的 retry 机制或分批次手动确认，不要一次性全量推送。