Linux 排障：权限、服务、空间与远程登录 · 权限、服务与资源故障定位至SSH 登录被拒绝
Linux 排障：权限、服务、空间与远程登录
权限、服务与资源故障定位
本节沿任务退出码、journal 和四个日志文件定位失败层；先确认服务账户、固定状态目录、flock 与 timer，与配套示例逐项对照，再选择最小修复。
前置是机制与任务契约。核对日期 2026-10-17，适用 GNU/Linux 与 systemd 249+。下面的错误是设计场景；命令和示例未执行，需在目标环境核对权限与影响。排查先保留时间、对象、版本与最近变更，再逐层缩小范围，不以反复重启替代判断。
Permission denied 的路径检查
Linux Permission denied 不等于“文件缺少写权限”。先核对服务的 User/Group 和实际凭据，再逐级看目录搜索权限、文件模式/ACL、强制访问控制、挂载只读状态与 systemd 沙箱。sudo 下运行成功只能提示身份差异，不能证明把服务改成 root 就是正确修复。
对维护任务，目录必须由实际任务 UID 拥有且为 0700，已有锁与日志必须为 0600 普通单硬链接文件。脚本打印 file needs owner=current user, mode=600, links=1 时应查明具体文件来源，不能直接 chmod -R 整个父目录。若是 SELinux/AppArmor 拒绝，先核对目标路径标签或策略，不能默认禁用保护。EnvironmentFile 读不到可能在脚本启动之前就失败，与脚本自己的 MAX_BYTES 校验是不同层。
systemd失败与timer未触发
Linux systemd failed 先区分管理器启动失败和脚本退出失败。User 不存在、工作目录缺失、解释器路径错误、环境文件缺失，都可能让 ExecStart 尚未进入任务代码；脚本打印 maintenance 前缀则说明已运行到自身检查。查看 Result、ExecMainStatus、journal 时间和完整合并后的单元，防止被旧 drop-in 误导。
Linux timer 未触发要核对 ActiveState、下一次触发时间、UTC 与本地时间、OnCalendar 表达式和 Persistent 状态。enable 不等于已经启动，timer active 也不证明上次服务成功。维护任务正常完成后 service inactive 是预期候选；不能为保持绿色 active 加 RemainAfterExit，因为保持激活会妨碍重复的定时 oneshot 启动。
# 只作日后观察示意，本轮未执行。
systemctl status showdocs-maint.timer showdocs-maint.service
systemctl cat showdocs-maint.service
systemctl show showdocs-maint.service -p Result -p ExecMainStatus
journalctl -u showdocs-maint.service --no-pager -n 50No space left on device
Linux No space left on device 应分别检查 df 的容量、inode、用户配额和实际写入挂载点。df 有空闲字节而新文件失败时，inode 或配额仍可能耗尽。du 与 df 差距大时，要考虑权限可见范围、不同挂载点、快照/预留空间和仍被打开的已删除文件；不能立即认定统计工具错误。
维护脚本先采集报告后轮转，df 失败时不会进入轮转；但后续删除、移动和追加不是事务，失败可能发生在中途。保留当前四个文件和错误码，先解除容量或只读状态原因，再恢复调度。不要为了腾空间删除 .lock：这不能解决日志占用，还会让并发实例使用不同锁对象。
网络不可达与拒绝连接
Linux Connection refused 通常说明连接遭拒绝，例如目标地址/端口没有监听或策略主动拒绝；timeout 表示在时间内没有完成，不能据此唯一定位防火墙。名称解析错误先查 DNS，再核对 IP、路由、监听地址和回程路径。ping 成功只说明某种 ICMP 往返，不能证明 HTTP、TLS 或应用就绪。
日后可分层读取 ip address、ip route、ss -lntp，再按权限与场景考虑网络探测。主机的 127.0.0.1 与容器内部回环不指向同一个命名空间对象。远程修改网卡地址导致 SSH 中断时，先走预先准备的带外通道恢复已保存配置，不能在失联终端继续猜命令；历史网卡实验的失败结果不是修复方案。
负载高与进程停止困难
Linux 负载高要把 CPU 使用、可运行队列、D 状态等待、内存压力和 I/O 延迟放到同一时间窗口比较。load average 不是 CPU 百分比，单次 top 或 uptime 不能证明瓶颈；需要正常基线和连续观察。主机内存足够而服务 OOM 时，也要查所属 cgroup 的限制与内核记录。
按名称 grep 后直接 kill -9 的历史脚本可能匹配多个程序或遗漏 PID 复用风险。优先核对服务名、进程启动时间和路径，正常停止服务或先发 SIGTERM；SIGKILL 是最后手段，也不能立即消除不可中断等待。僵尸需处理父进程的收集逻辑，不能对已经退出的实体重复施加终止操作。
练习与参考解答
题目：维护日志昨天有输出、今天 timer active，能否断定今日成功？脚本退出 75，是否应删除锁重试？
参考解答：需要核对今天的实际服务激活、退出码与 UTC 时间，active 只说明 timer 当前等待。75 表示锁忙，先确认哪个可信实例仍持锁及是否超时；删除锁破坏互斥，不能作为解锁手段。记录事实与假设分开，例如“触发时间已过但无本日激活记录”是事实，“时区配置错误”仍需证明。
进一步核对
内核 proc 说明解释状态观测接口；systemd v255 service 文档源码用于核对服务类型和退出生命周期。实际错误码描述以目标发行版同版本手册为准，不把相近报错归为一个根因。
网卡失联与失败路由实验的证据
网卡改址失联能否断言云平台封禁，路由添加是否互通？ 历史 CentOS 实验的可用结论是“操作发生后失联”和“跨网段尝试未成功”。原环境主接口与 docker0 曾同时出现重叠的 192.0.2.0/24 路由；复制 ifcfg 文件又填入不存在的设备名称，重启失败，直接改主网卡地址后 SSH 断开。后来通过控制台与重启恢复旧地址，不证明错误网卡名、云平台约束或安全机制中的某一个就是唯一根因。
另一实验在两台云主机添加对方网段路由，最终出现 Destination Host Unreachable。路由表有记录不是云网络互通证据，仍需证明下一跳可达、云侧连接和策略、目标监听与回程。traceroute 的星号仅表示该探测未获响应；telnet 收到 SSH banner 后输入任意文本产生 Protocol mismatch，说明连到了 SSH 协议端，不是用户认证失败。ping 的 ICMP 往返也不证明应用端口可用。
实际网卡名、DHCP/静态来源、运行地址与持久配置生成者需分别确认；直接写 resolv.conf 或 hostname 改提示符不等于持久生效。旧 net-tools route 语法、主机地址、复制网卡与修改 docker0 的命令撤回为部署方案，不改写为实验已成功。ARP、OSI、包、时间同步等旧空标题没有正文，不构成已完成课程。文件传输应核验 SSH 主机密钥，不能先删除整份 known_hosts；scp 的端口选项与 ssh 不同，rsync 需核对方向与通道，wget 下载成功不证明来源可信。
SSH 登录被拒绝
核对用户名、密钥选择和服务器授权。
Permission denied (publickey) 是认证失败，不一定是网络故障。先确认目标主机可信、用户名正确，再从详细日志查看客户端实际提供了哪把密钥。
排查步骤
1. 查看认证过程
ssh -v <user>@<host>预期结果: 日志显示尝试的身份文件及服务器接受或拒绝的位置。
2. 核对代理中的密钥
ssh-add -l预期结果: 列出预期密钥；若未加载，检查密钥路径和代理状态。
3. 明确指定一把密钥重试
ssh -o IdentitiesOnly=yes -i <private-key> <user>@<host>预期结果: 成功则说明默认密钥选择有误；失败则检查服务器上该用户的 authorized_keys。
常见报错
Permission denied (publickey)
原因: 用户名、私钥或服务器授权公钥不匹配。
处理方式: 核对用户和密钥指纹，以及服务端 authorized_keys 权限与内容。
Host key verification failed
原因: 可能是主机密钥变化、严格模式下未知主机，或 known_hosts 路径/权限与配置异常。先读详细错误，不能只凭这一行断言服务端重建。
处理方式: 通过可信渠道核对新指纹，再更新本地记录；不要关闭主机校验。
相关文档
官方资料
继续阅读
- 排错
- 排错
- 命令与系统观察