restorecon -Rv /etc/ssh 仅在 SELinux 标签错乱（如手动复制文件导致标签变为 default_t）且日志出现 avc: denied 时有效；它不修复语法错误、权限位、属主问题，也不生效于 SELinux 被禁用或端口未授权场景。
sshd 启动失败时，restorecon -Rv /etc/ssh 真的能解决问题？
不一定。这条命令只在 SELinux 标签错乱导致权限拒绝时才有效——比如你手动复制、移动过 /etc/ssh 下的文件，或用非 RPM 方式覆盖了配置。如果 sshd 报错是 Permission denied (publickey) 或 Failed to load host key，但日志里明确出现 avc: denied，那才值得试。
怎么确认真是 SELinux 标签问题？
先看实时拒绝日志：sudo ausearch -m avc -ts recent | grep sshd。如果有输出，且含 type=sshd_port_t 或 target=/etc/ssh/sshd_config，说明 SELinux 拦截了访问。再查当前标签：ls -Z /etc/ssh/，正常应显示 system_u:object_r:sshd_config_t:s0（配置）或 system_u:object_r:sshd_key_t:s0（密钥）。若全是 unconfined_u:object_r:default_t:s0，就是标签丢失了。
restorecon -Rv /etc/ssh 的实际效果和限制
这条命令只是把 /etc/ssh 下所有文件按 SELinux 策略恢复默认类型，不改内容、不修语法、不处理权限位（如 sshd_config 被设成 777 仍会报错）。它不会自动修复以下情况：
-
/etc/ssh/sshd_config文件本身语法错误（sshd -t会直接报错） - 私钥文件（如
ssh_host_rsa_key）属主不是root:root或权限不是600 - SELinux 策略被禁用（
sestatus显示disabled），此时restorecon完全无意义 - 自定义端口未在策略中放行（需
semanage port -a -t ssh_port_t -p tcp 2222）
比 restorecon 更该优先做的三件事
很多用户一看到 SELinux 就猛敲 restorecon，反而掩盖了真正问题：
- 运行
sshd -t验证配置语法——90% 的启动失败源于此 - 检查
journalctl -u sshd -n 50 --no-pager，找第一行 error，不是只盯Permission denied - 临时设为 permissive 模式：
sudo setenforce 0，再试启动；若成功，才是 SELinux 问题，否则是别的原因
SELinux 标签错乱只是表象，根源常是操作方式不对（比如用 cp 替代 install、用编辑器远程保存覆盖文件）。修完记得 setenforce 1，别留着 permissive 模式跑生产。
