修改 sshd_config 后，大多数配置可以通过重载服务生效，无需完全重启，但涉及监听端口等底层参数的修改仍需重启。
先说结论：优先使用重载命令应用配置，但需警惕部分参数必须重启才能生效，操作前务必保留当前会话。
- 适合：多数安全策略、认证方式、日志级别等配置调整
- 先准备：执行语法检查并保持一个已连接的 SSH 会话不要断开，注意 Linux 发行版服务名可能是 ssh 或 sshd
- 验收：尝试新建 SSH 连接确认配置生效，同时检查服务状态
命令速用版
如果你确认修改内容不涉及端口变更，可以直接使用以下命令重载配置：
systemctl reload sshd # 注意：Debian/Ubuntu 等发行版服务名通常为 ssh 而非 sshd systemctl reload ssh
在重载之前，建议先检查配置文件语法是否正确，避免服务启动失败：
sshd -t
如果系统没有使用 systemd，可以通过发送信号的方式重载（PID 路径可能因配置而异）：
kill -HUP $(cat /var/run/sshd.pid 或根据 sshd_config 中 PidFile 指定) # 更安全的方式是通过 pgrep 查找进程 kill -HUP $(pgrep -f sshd)
原理简述
sshd 服务设计支持通过接收 SIGHUP 信号来重新读取配置文件。当执行重载操作时，主进程会重新加载 sshd_config，但已经建立的连接会保持原有配置不变，新建立的连接才会应用新配置。这种方式避免了中断现有业务，但并非所有参数都支持动态加载，例如监听端口或地址家族的变更通常需要完全重启服务才能生效。
分步处理
1. 确认服务名：运行 systemctl status ssh 或 systemctl status sshd 确认当前管理的服务名称。
2. 语法检查：在应用任何更改前，先运行 sshd -t。如果没有输出，说明语法正确；如果有报错，必须修复后再继续。
3. 保留会话：务必保持当前 SSH 连接不断开。如果新配置有误导致服务无法接受新连接，你还可以通过当前会话进行修复。
4. 执行重载：运行 systemctl reload sshd 或 ssh。注意不要使用 restart，除非你确定需要重启。
5. 回滚准备：如果重载后无法新建连接，立即通过当前会话恢复原配置文件，并执行 systemctl restart sshd 恢复服务。
配置项生效方式对照表
| 配置项示例 | 生效方式 | 说明 |
|---|---|---|
| PermitRootLogin | reload | 认证策略，重载即可生效 |
| PasswordAuthentication | reload | 认证方式，重载即可生效 |
| PubkeyAuthentication | reload | 密钥认证，重载即可生效 |
| Port | restart | 监听端口，必须重启服务 |
| ListenAddress | restart | 监听地址，必须重启服务 |
| Protocol | restart | 协议版本，必须重启服务 |
怎么验证是否生效
1. 检查服务状态：运行 systemctl status sshd，确认服务处于 active (running) 状态且没有报错。
2. 查看有效配置：运行 sshd -T 查看当前生效的配置值，确认修改项已更新。
3. 新建连接测试：打开一个新的终端窗口，尝试 SSH 登录服务器。如果登录成功且符合新配置（例如禁止了密码登录则只能密钥登录），说明生效。
4. 查看日志：检查系统日志，如 /var/log/secure 或 /var/log/auth.log，确认没有认证错误或服务异常记录。
常见坑
1. 端口变更必须重启：如果修改了 Port 或 ListenAddress，重载通常不会生效，必须使用 systemctl restart sshd。
2. 现有连接不受影响：重载后，已经登录的用户 session 不会立即受到新策略影响（如空闲超时设置），只有新登录的用户才会生效。
3. 锁死风险：在修改认证相关配置（如 PermitRootLogin 或 PubkeyAuthentication）时，如果配置错误可能导致无法再次登录，务必保留一个特权会话用于急救。
4. 服务名称差异：CentOS/RHEL 通常为 sshd，Debian/Ubuntu 通常为 ssh，操作前请确认。