在RHEL环境中，sshd服务是远程维护的入口，一旦这个服务没有运行，管理员往往只能通过物理控制台或带外管理登录主机。当客户端出现Connection refused或No route to host时，通常意味着sshd进程没有监听端口。本文不讨论网络不通的情况，而是聚焦在系统内部sshd服务未启动的排查与修复。
一、确认sshd服务为何没有运行
登录服务器后，第一步不是反复执行启动命令，而是查看服务的当前状态。执行systemctl status sshd.service -l可以看到服务是否处于active状态，以及最近的启动失败原因。如果输出中包含failed或inactive，再尝试使用systemctl start sshd.service启动。此时终端通常会返回一段简短的错误信息，例如配置文件行号或密钥权限问题，这些信息是后续修复的关键。
systemctl status sshd.service -l systemctl start sshd.service
如果启动命令给出的信息不够明确，可以使用journalctl -u sshd --no-pager -n 50查看sshd服务最近的日志。日志里会记录sshd读取配置、加载HostKey以及绑定端口的详细过程。很多启动失败在日志中都有明确提示，比如Bad configuration option或Address already in use。此外，sshd -t是一个只检查配置文件语法和基本权限、不会真正拉起进程的命令。当你修改过/etc/ssh/sshd_config后，应该先用它验证配置，再重启服务。
sshd -t journalctl -u sshd --no-pager -n 50
这里要区分几种状态：如果服务单元被masked，执行启动命令会提示Unit sshd.service is masked，说明管理员通过systemctl mask禁用了服务；如果是inactive但能正常启动，可能是之前的手动停止或开机自启被关闭；而failed则说明启动过程中遇到了配置、权限或依赖问题。不同状态对应的处理方式差异很大，先看清状态再动手能少走弯路。
二、高频故障点与具体修复方法
配置文件的语法错误是最常见的sshd启动失败原因之一。sshd配置对格式要求严格，参数和值之间只能使用空格或制表符分隔。例如把Port 22写成Port=22，或者PermitRootLogin yes写成PermitRootLogin，都可能导致sshd -t报错。定位方法很简单，运行sshd -t会直接指出错误行号和具体参数名，用vim打开/etc/ssh/sshd_config修改后再次验证即可。
grep -n "Port\|PermitRootLogin" /etc/ssh/sshd_config sshd -t systemctl restart sshd.service
第二类高发问题是HostKey文件权限不正确。sshd启动时会加载/etc/ssh/ssh_host_rsa_key等私钥文件，这些文件必须只能由root读写。如果管理员执行过chmod -R 777 /etc/ssh，或者从其他机器拷贝密钥时保留了错误的权限，sshd会拒绝启动，并提示Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open。修复方式是把密钥文件权限改为600，所有者恢复为root。执行以下命令后重启服务：
ls -l /etc/ssh/ssh_host_*_key chmod 600 /etc/ssh/ssh_host_*_key chown root:root /etc/ssh/ssh_host_*_key systemctl restart sshd.service
SELinux上下文错误也经常导致sshd启动后立即退出或无法监听端口。在启用SELinux的RHEL主机上，如果配置文件或密钥文件是从其他位置复制过来的，可能带有错误的安全上下文。例如/etc/ssh/sshd_config被标记为etc_t以外的类型，sshd进程就无法读取它。通过ls -Z /etc/ssh/sshd_config查看上下文，执行restorecon -Rv /etc/ssh可以批量恢复该目录下所有文件的默认SELinux标签。如果日志中出现SELinux阻止提示，这个方法通常能快速解决。
ls -Z /etc/ssh/sshd_config restorecon -Rv /etc/ssh systemctl restart sshd.service
端口冲突和监听地址错误是另一类隐藏较深的原因。如果管理员把Port改成了2222，但该端口已经被其他服务占用，sshd启动时会报Address already in use。使用ss -tulnp查看端口占用情况，确认后要么修改sshd配置换一个端口，要么停掉占用端口的进程。同时还要检查ListenAddress参数，如果设置为一个本机不存在的IP地址，sshd也无法正常绑定。
ss -tulnp | grep ssh ss -tulnp | grep ':22 ' grep -n "ListenAddress\|Port" /etc/ssh/sshd_config
三、修复后的验证与长期预防
修复操作完成后，不要直接关闭当前控制台去测试SSH登录，否则一旦配置仍有问题，可能就再也连不回来。正确的顺序是先执行sshd -t确认没有语法错误，再执行systemctl restart sshd.service重启服务，然后用systemctl is-active sshd.service查看是否返回active。确认服务状态正常后，再开启一个新的终端窗口尝试SSH连接。当前控制台保持打开，直到远程登录成功再关闭。
sshd -t && systemctl restart sshd.service systemctl is-active sshd.service systemctl status sshd.service -l
确认sshd可以正常启动后，需要把它加入开机自启，避免重启服务器后服务再次丢失。执行systemctl enable sshd.service即可。对于重要服务器，还应配置服务监控或告警，例如使用systemd自身的失败通知机制，或者通过外部监控工具定期探测22端口。日志审计也不能忽略，/var/log/secure会记录所有SSH登录尝试，定期检查能发现异常登录行为。
systemctl enable sshd.service systemctl list-unit-files | grep sshd tail -n 100 /var/log/secure
如果服务器运行在云平台或虚拟化环境中，强烈建议保留VNC、串口控制台或云厂商的远程救援功能。sshd故障时，这些带外管理渠道是恢复系统的唯一入口。日常维护中，修改sshd_config前先备份原文件，修改后立即运行sshd -t，可以大大降低因配置错误导致服务无法启动的风险。把这几项习惯固化下来，sshd未启动的问题就不再棘手。