Episode Details

一条写在 PAM `auth` 栈中的 SSH 封禁规则，看似严密，却可能被公钥认证完全绕过。本文复盘了一个真实运维陷阱：OpenSSH 在处理公钥认证时不会调用 PAM 的认证流程，因此“认证成功后是否仍允许该账号登录”不能依赖 `auth` 栈判断。 节目将深入解析认证与授权的边界，以及为何应将可靠的访问控制放入 PAM `account` 栈。它不仅适用于 SSH 封禁，也为设计系统级账号控制规则提供了重要思路。建议结合原文阅读，理解 PAM 控制语义、模块选择与不同进程入口带来的安全差异。 原文链接： https://utcc.utoronto.ca/~cks/space/blog/linux/SSHBlockLoginsWithPAM 原文标题：Blocking SSH logins with PAM (at least on Linux) 主要内容： • 公钥认证时，`sshd` 验证签名和 `authorized_keys` 的过程不会经过 PAM `auth` 栈，依赖该阶段的封禁规则可能失效。 • “持有私钥、通过身份验证”与“是否被允许使用系统”是两项独立决策；后者属于账号授权控制。 • 启用 `UsePAM` 后，SSH 的各种认证方式在最终放行前都会经过 PAM `account` 栈，因此账号封禁应部署在这里。 • 可借助 `pam_succeed_if` 判断用户 shell 等属性，并结合 PAM 的跳转控制语法、`requisite` 与 `pam_deny` 实现明确的拒绝策略。 • 规则写入哪个 PAM 配置文件决定了防护边界：仅限制 SSH，还是同时覆盖 lingering 用户服务、cron 任务及既有进程等其他入口。 推荐理由： 这是一篇极具实战价值的 Linux 运维文章。它指出的并非配置语法问题，而是安全设计中最容易被忽略的执行路径问题：规则写得正确，不代表所有关键路径都会经过它。通过这个案例，你能更清晰地区分认证与授权，并重新审视 SSH、PAM 和系统账号生命周期中的真实安全边界。 --- 「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。 由 voieech.com 提供技术支持。