服务器远程登录加固资源包：配置备份、连通性验收与回滚检查表

在维护 linux 服务器或云主机时，远程登录安全加固往往是上线合规的第一步。然而，许多运维人员与站长常因直接修改 /etc/ssh/sshd_config 或调整认证模块，导致会话瞬间中断，将自己彻底锁在系统之外。远程加固的核心并非单纯罗列安全策略，而是建立一套可验证、可停止、可回滚的标准运维工作流。在进入变更之前，必须始终确保云厂商的 VNC/控制台或本地带外管理（如 IPMI）处于可用状态，作为极端情况下的保底入口。

变更前置准备与基线备份

任何加固变更都不应跨发行版直接套用统一配置文件。CentOS/RHEL、Debian/Ubuntu 与 openEuler 等系统在默认 PAM 堆栈、配置目录拆分（如 sshd_config.d）上均有差异。变更前，必须对受影响的配置文件做权限完备的物理快照或目录归档。

1. 配置备份清单与权限控制

备份文件如果直接存放在公网可读目录或赋予宽泛权限，极易泄漏系统公私钥映射与安全规则。所有备份必须集中至 root 属主且权限严格限制的独立隔离目录中：

# 创建具备严格属主与权限的专用备份目录
sudo install -d -m 700 /root/backup_ssh_$(date +%F)

# 备份 SSH 守护进程配置及拆分片段
sudo cp -a /etc/ssh/sshd_config /root/backup_ssh_$(date +%F)/
[ -d /etc/ssh/sshd_config.d ] && sudo cp -a /etc/ssh/sshd_config.d /root/backup_ssh_$(date +%F)/

# 备份 PAM 认证链配置
sudo cp -a /etc/pam.d /root/backup_ssh_$(date +%F)/pam.d_bak

# 备份管理账户的公钥授权映射与权限核对
sudo cp -a ~/.ssh/authorized_keys /root/backup_ssh_$(date +%F)/authorized_keys_bak

2. 变更前检查表（Pre-Check）

在敲下任何修改指令前，对照完成以下环境自检并签字确认：

• [ ] 应急通道核实：已登录云服务商控制台（VNC/救援终端）并成功完成一次带外登录测试。
• [ ] 普通运维账户验证：已存在具备 sudo 提权能力的非 root 账号，并能成功执行特权指令。
• [ ] 密钥登录可用性：该普通账号已导入有效公钥，其本地 ~/.ssh/ 目录权限为 700，authorized_keys 权限为 600。
• [ ] 配置与防火墙状态记录：已核对当前防火墙策略（iptables、firewalld 或云安全组），避免加固策略被安全组先行阻断。

最小加固操作示例与语法检查

安全加固不等于“修改端口号”。隐蔽端口无法替代身份认证加固，真正的核心在于收敛攻击面：禁止空密码、禁用 root 直连、强制使用密钥认证。以下以一台获得明确运维授权的测试主机为例，演示安全收敛变更。

1. 最小变更示例

使用文本编辑器调整 /etc/ssh/sshd_config（或其子配置文件）：

# 基础安全加固策略
PermitEmptyPasswords no
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

注意：若业务网络需要变更监听端口，除在配置中声明 Port <新端口> 外，必须同步在系统防火墙和云控制台安全组放行该端口，切忌在端口未放通前关闭原有连接。

2. 配置语法静态核验

编辑完成后，严禁立即重启服务。必须先调用 SSH 守护进程内置的测试参数验证配置语法及逻辑是否存在解析错误：

# 测试配置文件语法合法性（静默且无报错即为通过）
sudo sshd -t

# 若希望查看实际生效的完整运行时配置参数（包含默认继承项）：
sudo sshd -T | grep -E "(permitrootlogin|passwordauthentication|pubkeyauthentication)"

如果 sshd -t 返回非零状态或输出具体报错行号，必须立即修正，禁止执行服务重载。

双会话验收与连通性验证

服务变更过程中，最忌讳的是“修改配置后立即退出当前会话并重新登录”。一旦配置出现死锁，当前唯一可用的交互式连接就会彻底丢失。

[ 会话 A (维护中) ] ──> 重载配置 (sshd -t && reload) ──> 维持连接、观察日志
                                                               │
[ 会话 B (新终端) ] ──> 发起测试连接 (ssh -p <端口> user@host) ──┤
                                                               │
        ┌──────────────────────────────────────────────────────┴───────────────┐
        ▼                                                                      ▼
  【验证成功】                                                            【验证失败】
  1. 确认 sudo 提权正常                                                   1. 保留会话 A 状态
  2. 确认密码拒绝/密钥生效                                                2. 检查 /var/log/secure 或 auth.log
  3. 签字关闭会话 A                                                       3. 立即从会话 A 执行回滚

1. 保持当前会话 A 不断开

会话 A 仅负责服务重载与监控：

# 使用 reload 平滑加载，避免直接 restart 导致异常断开存量连接
sudo systemctl reload sshd

# 开启实时日志跟踪，观察后续连接握手
# Debian/Ubuntu 系列：
sudo tail -f /var/log/auth.log
# CentOS/RHEL/openEuler 系列：
sudo journalctl -u sshd -f

2. 开启新终端会话 B 进行验收

在本地开发机或跳板机开启全新的命令行终端（会话 B），依次执行连通性验收：

1. 测试管理账户密钥登录：

   ssh -i ~/.ssh/id_rsa -p 22 <运维用户名>@<服务器IP>

预期结果：正常通过密钥认证进入 shell，无需输入系统登录密码。

1. 测试特权提权能力：

在会话 B 中执行 sudo whoami。 预期结果：正确提示输入该用户的提权密码，并返回 root。

1. 测试越权行为被拒绝：

尝试通过 root 或弱口令方式登录：

   ssh -o PubkeyAuthentication=no root@<服务器IP>

预期结果：连接被明确拒绝（如 Permission denied (publickey)），且在会话 A 的日志流中能观察到合规的审计拒绝记录。

故障回滚记录与检查表

如果双会话验收在会话 B 遭遇阻断（例如密钥无法被识别、PAM 模块锁定或权限拒绝），切勿关闭会话 A。应立即依赖会话 A 启动回滚流程。

1. 紧急回滚执行步骤

# 步骤 1：利用前期备份的独立文件全量覆盖受影响配置
sudo cp -a /root/backup_ssh_$(date +%F)/sshd_config /etc/ssh/sshd_config
[ -d /root/backup_ssh_$(date +%F)/sshd_config.d ] && sudo cp -a /root/backup_ssh_$(date +%F)/sshd_config.d/* /etc/ssh/sshd_config.d/
[ -d /root/backup_ssh_$(date +%F)/pam.d_bak ] && sudo cp -a /root/backup_ssh_$(date +%F)/pam.d_bak/* /etc/pam.d/

# 步骤 2：再次静态检测语法有效性
sudo sshd -t

# 步骤 3：重载守护进程恢复基线
sudo systemctl reload sshd

# 步骤 4：在会话 B 重新发起基线连通性测试

2. 变更记录与回滚归档表模板

运维团队在完成加固或故障复盘时，应沉淀完整的变更日志备查：

将加固操作转化为闭环的检查流程，能消除“加固即失联”的运维风险。无论是在单台 VPS 部署个人站点，还是批量加固企业生产集群，严守控制台兜底、文件先备份、语法先检测、双会话验收四大纪律，即可在保障主机边界安全的同时，维持业务运维的高可用性。