几个人都能 root 登服务器，出事怎么查是谁干的：SSH 私钥治理与操作留痕的正确顺序

端口改了、密码关了，出事还是查不出是谁：漏的是哪一步

有两个团队出过几乎同一件事。第一个团队花了一周做"加固"：SSH 端口从 22 改成一个五位数，PasswordAuthentication 关掉，fail2ban 装上，root 直接登录禁掉。看起来相当扎实。两个月后有人误删了一个数据目录，回头排查能拿到的只有一行日志：Accepted publickey for root from 1.2.3.4。因为三个人用的是同一把私钥，谁拿它登进来，这行日志长得一模一样。history 是空的——那个人退出前顺手清掉了。谁干的，查不出来。

第二个团队端口还开着 22。他们只做对了两件事：一人一把私钥、每把都带口令；所有登录必须先过一台统一入口机器，入口上开了会话录制。同样一次误删，他们拿到的是：哪个账号、几点几分、从哪个来源 IP、进的哪台机器、敲的每一条命令和每一行回显。

差别不在"防得多严"，而在有没有把一次操作对上一个人。这才是多人共用服务器时真正的分水岭。很多人把力气花在"怎么让外人进不来"，却没花一分钟想"进来的人干了什么我能不能留下来"。前者是门禁问题，后者是归因问题，两件事的技术栈完全不同，投入顺序也完全不同。

先把问题重新定义：不是"能不能登进来"，是"能不能对上人"

服务器登录这件事其实有三层问题，很多人只盯着第一层。

第一层是认证：谁能进来。密码、公钥、证书、双因素，都在这一层。第二层是授权：进来之后能干什么。能不能 sudo、能 sudo 哪些命令、能不能读别的业务目录，这是权限边界的问题。第三层是归因：事后能不能把某一条具体操作，唯一地对应到某一个人身上。

绝大多数团队在第一层上投入过度，在第三层上投入为零。端口改了、密码关了、密钥登录开了，第一层基本就算交差了。可一旦真出了事故——误删、误改配置、数据被拖走、业务莫名重启——你要回答的是第三层的问题。这时候才发现，前面所有的努力都对这个问题没有帮助。

更麻烦的是顺序。第三层的东西不是可以后补的：私钥一旦复制得到处都是，你事后没法回溯"这把 key 当时在谁手上"；共用 root 账号一旦形成习惯，你事后也没法把某条命令分给某个人。这两件事必须在出事之前定好，出事之后再补，补不上。

所以这篇文章的结论很直接：先把归因做起来（一人一钥、私钥带口令、收敛登录入口），再把留痕做起来（sudo 日志、执行审计、会话录制），排在最末位的才是加固（改端口、关密码、限制来源）。顺序倒了，前面的功夫大半白做。

authorized_keys 这个文件才是真正的权限清单：多一个人就多一行

很多人把"开了密钥登录"当成一件做完了的事。其实开了密钥登录之后，你真正的权限清单是每台机器上那个 ~/.ssh/authorized_keys 文件——多一个人，就往里多加一行公钥。这个文件才是你实际的访问控制列表，而它通常没有任何版本管理、没有审批、没有过期时间。

SSH 公钥认证的流程本身很简单：客户端拿着私钥对服务端发来的会话标识做签名，服务端拿 authorized_keys 里登记的公钥去验签，验过了就放行。服务端从来不知道你私钥文件长什么样，也不知道你私钥有没有口令、是不是刚从别人 U 盘里拷来的。它只认"这把公钥在我名单里"。

这就决定了散装公钥的几个天生缺陷。公钥只是一串文本，转发、粘贴、进聊天记录都不掉价，复制出去之后原主人毫无察觉。它没有身份信息，你要知道这行是谁的，只能靠行尾那个 comment 字段——而那个字段是生成密钥时手敲的，可以随便改，也可以完全没有。authorized_keys 里堆到二十行之后，没人记得哪行对应哪个人、哪行是三个月前外包留下的。

存放位置与权限要求是硬性的：~/.ssh 目录要 700，authorized_keys 文件要 600，属主是对应账号。sshd 默认开 StrictModes，属主或权限不对会直接拒绝使用这个文件——这个机制值得感谢，它至少保证了"谁能写这个文件"等同于"谁能给自己开权限"。

还有一个更隐蔽的坑：这个文件通常不在任何备份和监控的视野里。业务代码有仓库、有评审，配置文件多少还有人看一眼，而 authorized_keys 是纯粹的手工产物，改了不通知任何人。等你发现某台机器上多了一行认不出来的公钥，它大概率已经在那儿挂了很久。对这个文件的正确态度是：它和防火墙规则同级，任何变动都要留痕。

单行公钥前面其实是可以加限制项的，这一点被严重低估：command="..." 强制登录后只能跑指定命令，from="1.2.3.0/24" 限定来源地址，no-port-forwarding 禁端口转发，no-agent-forwarding 禁代理转发，no-pty 不给交互终端，OpenSSH 7.2 之后还有 restrict 一次性把所有限制都打开。给备份脚本、同步任务、监控探针这类机器账号用带限制项的公钥，比给它一个完整 shell 安全得多，也更好审。

私钥要带口令：ssh-agent 是方便，但它也会把能力借出去

一把没有口令的私钥，等于一个写在外面的密码文件。它落在笔记本上、落在跳板机的 home 目录里、落在某个备份压缩包里，任何拿到这个文件的人都能直接用，不需要再过任何一道。给私钥加口令（ssh-keygen 生成时设置 passphrase），至少要满足"拿到文件"和"知道口令"两个条件才能用，这是成本极低收益极高的一步。

加了口令之后每次登录都要敲一遍太烦，于是有了 ssh-agent：把解了密的私钥缓存在内存里，本次会话登录时自动取用，口令只敲一次。ssh-add 负责往里塞，ssh-add -l 看当前缓存了哪些。这一步本身没问题，问题出在 ForwardAgent。

开了 agent forwarding 之后，你登上的那台远程机器可以通过 socket 反向使用你本地 agent 里的私钥——也就是说，你在跳板机上开的这个转发，等价于"把我的登录能力临时借给这台机器"。在这台机器上拥有 root 的人，能够在你连接的这段时间里用你的身份去登录别的机器，而目标机器上的日志只会记成是你。这类风险点到为止，不展开具体做法，你只要记住结论：跳板机上开 agent forwarding，是把你的身份借给那台机器的所有人。真有需要跨跳板的情况，用 ProxyJump 做连接跳转，让认证始终发生在本地，比转发私钥能力干净得多。

共用 root 的代价：无法归因、误操作无责、离职清不干净

共用账号是归因的头号杀手，不管是共用一个 root 密码，还是共用一把 root 私钥，后果完全一样。

无法归因是最直接的：日志里所有人都是 root，一条 rm 出来，你连问谁都不知道该问谁。误操作无责是第二层——当大家都知道"反正查不出来"，操作就会变随意，变更前不确认、生产环境直接试命令这类事会明显变多，这不是人的问题，是机制给了暗示。离职清不干净是第三层：一个人走了，你不知道他手上到底有几把 key、都塞在哪几台机器上，最省事的做法是把所有 authorized_keys 全量重刷一遍，而绝大多数团队不会真这么做，于是那几行公钥就在机器上挂到服务器报废为止。

PermitRootLogin 有几个取值值得分清：prohibit-password 是不允许密码方式登 root（公钥仍可），no 是完全不允许 root 直接登录，forced-commands-only 是只允许执行 authorized_keys 里 command= 指定的命令。日常运维该走的路子是 no + 个人账号登录 + sudo 提权，这样每条提权动作才挂得上具体的人。再配 AllowUsers 或 AllowGroups 做白名单，比逐个封禁省事，白名单的默认语义是"名单外一律拒绝"。

history 靠不住：关掉它的方法不止一种，所以它不能当证据

很多人以为 ~/.bash_history 就是操作记录。它不是，它只是一个给使用者自己图方便的回溯工具，而使用者恰好是那个最想删掉记录的人。

bash 的 history 是在 shell 正常退出时才写回文件的。这意味着一个进程被强杀，这次会话的命令就不会落盘。unset HISTFILE 可以让本次会话完全不写文件，export HISTCONTROL=ignorespace 之后命令前加个空格就不记录，history -c 清内存里的记录，set +o history 直接关掉。具体手法就说到这里，你只需要知道：能关掉它的入口有好几个，而且全在使用者自己的权限范围内。

加上共用账号这一条更致命——就算 history 完整留着，你也只看到"root 敲了这条命令"，还是对不上人。所以它既不能当证据，也不能当审计记录，最多算个辅助线索。真正能当依据的日志，必须写在使用者改不了的地方：root 才能写的目录下、远程日志服务器上、或者从内核层采集。

sudo 那层能记什么：log_output 与 sudoreplay 能补上哪一段

su - 和 sudo 的差别，在留痕这件事上是决定性的。su - 是把整个会话变成 root，之后你在里面敲什么，系统只知道是 root 在敲；sudo 是逐条命令提权，每条都会记一笔"谁在什么时候用 sudo 跑了什么"。

默认配置下，sudo 记的是命令调用本身，进 /var/log/secure（RHEL 系）或 /var/log/auth.log（Debian 系），格式大致是用户名、终端、执行目录、被执行的命令。sshd 的登录成功日志也在这里，会带上用的哪把公钥的指纹——这一条很有用，前提是你得先把公钥和人对应起来，也就是前面说的"一人一钥"。

sudo 还能再往前走一步：Defaults log_output（或针对单条规则加 LOG_INPUT/LOG_OUTPUT 标签）会把命令的输入输出一起录到 /var/log/sudo-io 下。sudoreplay -l 列历史会话，sudoreplay 加会话 ID 回放。开了这个，一次 sudo 操作的完整终端过程就能事后重放，说服力比一行命令文本强得多。

但它有两个必须知道的边界。一是 sudo -i 或 sudo su - 一旦给了完整 shell，shell 内部再敲什么就不在 sudo 的记录范围内了——所以给 sudo 权限时应该按命令白名单给，而不是图省事给 ALL。二是日志在本机，拿到 root 的人理论上就能动它，所以日志要往外发一份才叫审计记录。

auditd 补的是"执行了哪个文件"：与 sudo 日志不是同一层

sudo 日志记的是"人通过 sudo 跑了什么"，auditd 记的是"内核看到哪个可执行文件被运行了"。两者不是替代关系，是互补，因为覆盖的口径不一样。

auditd 的用法是加规则：auditctl -w /usr/bin/rm -p x -k del_cmd 表示监视这个路径的执行（-p x 即 execute），打上 del_cmd 这个标记；事后用 ausearch -k del_cmd 检索。它能抓到不经过 sudo 的执行路径——比如进程自己拉起的、某个服务账号直接跑的。

它最有价值的一条是 auid（登录 uid）。这个字段记录的是最初登录系统的那个人，不会因为你 su 到 root 就变。也就是说，即使某人提权之后换了身份，auditd 依然能把动作挂回最初登录的那个账号——这正是共用 root 场景下最缺的那条线索。查的时候用 ausearch 按用户过滤即可。

代价是规则要自己设计，且规则写得太宽会产生海量日志。-w 监视目录时更要小心，目录级规则是递归的，落在 /tmp 这种地方基本等于日志洪水。常见的做法是只盯关键路径（敏感数据目录、关键二进制、配置目录），配合 key 做检索，日志同样要转发到本机之外。

会话录制和命令日志的差别：记录强度与存储成本怎么权衡

命令日志和会话录制是两种不同强度的东西，选哪个取决于你要回答什么问题。

命令日志（sudo 日志、auditd）体积小、检索快、结构化，适合回答"有没有人动过这个文件""谁重启过这个服务"。但它只能告诉你命令被敲出去了，告诉不了你命令执行时屏幕上出现了什么，也覆盖不到那些绕过记录通道的交互。

会话录制是把整个终端的输入输出按时间轴录下来，script 命令是最朴素的实现，tlog 是专门为这个场景做的（可以直接挂在登录环节上），asciinema 那类工具走的是另一种思路。录制的好处是还原度高，回显、报错、中间过程全在；代价是存储——交互式会话的输出量远大于命令文本，运维高峰期尤其明显，而且回放检索比 grep 日志慢很多。

还有一点容易被忽略：录制的存在本身要让人知道。在登录横幅或内部规范里写明"本会话会被记录"，既是对合规要求里告知义务的回应，也实实在在会降低随意操作的概率。记录强度再高，也只是事后能查；让人知道会被记录，是事前就少出事。这两件事不冲突，应该一起做。

务实的分层是：所有机器的 sudo 日志和执行审计都开（成本极低，覆盖日常八成问题），会话录制只开在统一入口和少数高敏机器上（成本高，覆盖真正需要取证的场景）。录制数据的保留周期、谁能看、看的时候要不要再记一笔，这些也该提前定，否则录制库本身会变成一个新的敏感资产。

统一入口（跳板）真正的价值：不是多一道登录，是留痕与收敛入口

很多人对跳板机的理解是"多一道登录更安全"。这个理解不准，因为多一道登录并不天然带来任何安全收益——如果内网机器依然允许从任何地方直连，那这道跳板就是摆设。

它真正的价值有两个。第一是收敛入口：把"谁能登内网机器"这个规则从 N 台机器收敛到 1 个地方。做法上，内网机器的 sshd 只接受来自跳板地址的来源限制（AllowUsers ...@跳板IP 或防火墙层面收口），其他人想进来只能先过跳板。这样你要审计的访问控制点从几十个变成一个，要开的日志也只在一个地方开。

第二是留痕的位置变得可靠。在业务机上开审计，能拿到 root 的人就能动日志；在跳板上开，业务机的 root 管不到跳板，日志天然隔离。而且只有入口收口了，录制才是完整的——否则人家绕开跳板直连，你就什么都录不到。顺序很关键：是先收口入口，再在入口上开录制；反过来做，录出来的只是一部分人的操作。

这里也正好说清楚一件事：这类治理能不能做起来，取决于你对操作系统有没有完全控制权。用共享虚拟主机或者受限的托管环境，sshd 配置、sudo 规则、auditd 内核审计这些全都不是你能动的。一万网络深耕 IDC 19 年（成立于 2007 年），提供的是独立服务器租用这类机器完全归你自己管的形态——root 权限、登录策略、审计组件都由你自己定，上面这套东西才有落地的土壤。具体配置以官网实时显示为准。

用 SSH 证书替代散装公钥：签发、有效期、吊销这三件事

散装公钥的所有毛病，根子在"它就是一串没有身份、没有期限、没有吊销机制的文本"。SSH 证书认证正好补上这三个洞。

做法是建一个证书颁发密钥（CA），sshd 那边配 TrustedUserCAKeys 指向 CA 的公钥，之后不再往 authorized_keys 里塞个人公钥，而是由 CA 给用户的公钥签名发一张证书：ssh-keygen -s 指定 CA 私钥，-I 给一个证书 ID（一般写人名的标识），-n 指定这个证书能登录哪些账号，-V 指定有效期。

这一改带来三个直接收益。签发环节变成了必经的审批点，谁拿证有记录，而不再是"自己把公钥贴上去"。有效期是硬约束，证书过期就登不进来，默认就实现了轮换，不用靠人记得去删行。吊销有了正式机制——把证书写进吊销列表（用 ssh-keygen -k 生成 KRL），sshd 配 RevokedKeys 指向它，一个人离职，一条记录就让他手上所有证书立刻失效。

成本是你要维护一套签发流程和一个 CA 私钥，小团队可能觉得重。判断标准很简单：机器和人的数量到了"你记不住 authorized_keys 里哪行是谁"的程度，就该上证书了。在那之前，一人一钥加好命名规范也还能撑一阵。

机器一多就一定失控：为什么 authorized_keys 必须交给配置管理

人肉管理 authorized_keys 在三台机器以内还能凑合，超过这个数量一定会失控，而且是那种没人承认的失控：某台机器上多了一行不知道谁的公钥，没人知道它是怎么来的、什么时候来的、还在不在用。

原因是手改这个动作天然没有记录。你在 A 机器上加了一行，忘了在 B 机器上也加，下次有人登不上去，你又上去手工补一行——几次之后，N 台机器上的 authorized_keys 各不相同，谁也说不清"当前正确的版本"是哪个。更糟的是临时授权：为了赶一次上线给外包加的一行，往往就没有然后了。

解法是把这个文件交给配置管理工具统一分发。人名的公钥集中放在一个仓库里，机器上的 authorized_keys 由工具渲染生成，谁想加人必须提交变更。这样每一次权限变动都变成一次可回溯的提交，能看是谁批的、什么时候加的、什么时候删的；机器多了也不怕，一次推送全量对齐；离职清理也从"去每台机器上找"变成"仓库里删一行，全量下发"。

这也是为什么从行业部署角度看，机器规模一上来就该把登录权限纳入配置管理，而不是等出事再补。有些团队选择的是统一入口 + 集中认证的路子，本质上解决的也是同一个问题：把分布式的权限状态收敛成单点可管理的状态。

落地顺序清单：一人一钥 → 私钥加口令 → 收敛入口 → 开日志 → 定期审计

把整篇文章收成一条可执行的顺序，按这个走，前面的每一步都会让后面的步子更省力。

一人一钥。 每个人生成自己的密钥对，公钥行尾写清楚是谁、哪天生成。共用密钥立刻废掉重发。这一步不做，后面所有日志都对不上人，等于白做。

私钥带口令。 已有私钥可以补加口令。自动化场景单独发不带口令的密钥，并在服务端用 command=、from=、restrict 把它锁死在只能做那一件事上，不要和人的密钥混用。

收敛入口。 禁止 root 直连（PermitRootLogin no），个人账号登录后再 sudo 提权；用 AllowGroups 做白名单；内网机器的来源限制到跳板地址，让直连在物理上走不通。入口没收口之前开的录制，只是录了一部分人。

开日志。 sudo 开 log_output，配好 sudoreplay 的检索；关键路径上 auditd 规则；入口机器开会话录制；所有日志往本机之外转发一份，转发目标机器上的运维人员不能同时是业务机的 root。改端口这件事放在这一层的末尾——它主要作用是减少扫描噪音，对归因没有任何帮助，别把它当主菜。

定期审计。 每季度过一遍 authorized_keys：有没有认不出的行、有没有已离职的人、有没有该带限制项却没带的。有条件的把这一步做成自动化比对，仓库版本和实际机器状态不一致就告警。

这一整套只有在你完全掌控操作系统的前提下才做得起来。独立服务器租用形态下，sshd 配置、sudo 规则、内核审计、日志外发都由你自己说了算——一万网络深耕 IDC 19 年（成立于 2007 年），做的就是这个层面的事；具体配置以官网实时显示为准。反过来，如果你的机器是别人代维、登录方式由对方定，那这套流程能不能落地，得先问对方给不给你 root 和 sshd 的配置权。

各做法的真实边界对照

多人共用服务器时，登录这块最常被问到的几个问题

问：三四个人共用一台机器，一定要上跳板吗？
不一定。人少机器少的时候，一人一钥 + 私钥带口令 + sudo 日志 + 日志外发，已经能覆盖绝大部分排查需求。真正触发上跳板的信号有两个：一是你要对外部人员（外包、兼职、临时支援）开放登录；二是有人开始明确要求"操作要有记录"。这两个场景下一个统一入口省下的事，远多于维护它的成本。

问：私钥加了口令，自动化脚本怎么办？
把人的密钥和机器的密钥分开。自动化用单独的密钥对，不加口令，但服务端那行公钥必须带限制项：command= 锁死能跑的命令，from= 限定来源地址，再加 restrict 或 no-pty、no-port-forwarding。这样即使这把私钥泄露，拿到的人也只能在你限定的那一个用途上使用。千万别为了方便，把运维人员的密钥复制一份给脚本用。

问：改 SSH 端口到底有用吗？
有用，但用处非常有限，主要是把那些扫全网的自动化脚本挡在日志之外，让 /var/log/secure 干净一点，方便你真出事的时候看清条目。它对任何有针对性的访问没有作用，对"查不出是谁干的"这个问题贡献为零。把它当成加固清单里的一项可以，把它当成主要手段就本末倒置了。

问：sudo 日志能不能事后改掉？
在本机上，拿到 root 的人理论上就动得了本机的文件，所以本机日志不能单独作为审计依据。这也是为什么一定要把日志转发到另一台机器上——那台机器的管理权限要和业务机的 root 分开。日志外发 + 会话录制放在入口机，才是能站得住的组合。

问：外包人员怎么给权限比较合适？
几个原则：单独账号，绝不共用；账号名带得上人，别叫 ops 这类谁都能用的名字；sudo 按命令白名单给，不要给 ALL；公钥加 from= 限定来源；如果是短期项目，用 SSH 证书签一张带有效期的，到期自动失效，省得忘了回收。

问：人离职了，怎么保证密钥真被清掉？
靠"记得去删"一定会有漏网的。可靠的做法有三层：一是所有机器的 authorized_keys 由配置管理统一分发，离职时在仓库里删一行，全量下发，可验证；二是用 SSH 证书并维护吊销列表，一条记录让他手上所有证书同时失效；三是定期审计，逐行比对机器上的实际状态和仓库里的名单，不一致就告警。三条里至少做到前两条。

问：auditd 规则该盯哪些路径？
宁少勿多。优先盯三类：敏感数据目录、关键配置文件所在目录、少数几个高危动作对应的二进制。目录级 -w 是递归的，盯着 /tmp 或者业务日志目录这类高频读写的地方，日志量会瞬间失控，反而淹掉真正有用的条目。规则配好之后先观察一段时间日志量，再决定是否加宽。

问：会话录制存多久合适？
没有统一答案，取决于你的合规要求和存储预算。可行的分档是：命令类日志（sudo、auditd）保留半年到一年，体积小，检索价值高；完整会话录制保留一到三个月，或者只在入口机和高敏机器上开。定下来之后要写成明文规定，包括谁能查看录制、查看行为要不要再记一笔。

这篇里的机制依据是什么，哪些要你在自己机器上核

本文所述内容是 Linux 与 OpenSSH 的公开机制说明，包括公钥认证的验签流程、authorized_keys 的权限要求与可用限制项、私钥口令与 ssh-agent 的工作方式、sudo 与其 I/O 日志、auditd 的规则与检索、以及会话录制这一类思路的取舍。属于通用技术分析，不构成对任何具体产品或配置的承诺。

有三类东西请务必在你自己的机器上核一遍。一是路径与默认配置：日志文件在 RHEL 系通常是 /var/log/secure，Debian 系是 /var/log/auth.log，审计日志位置、sudoreplay 的存储目录也随发行版和版本变化；sshd 各项的默认值同样随版本演进（比如 PermitRootLogin 历史上有过取值名的调整，restrict 这类聚合选项是较新版本才有的）。二是版本门槛：证书认证、KRL、expire-time 这些能力对 OpenSSH 版本有要求，老版本上不一定可用。三是你自己的现状：现在机器上到底有多少行 authorized_keys、其中几行认得出人、几行带了限制项，这个数字只有你自己查得出来，也是这篇里唯一建议你今天就动手的事。

需要明确的是：本文未做任何实测、跑分或渗透测试，所述均为机制层面的说明；涉及可被滥用的手法时只点到"存在这类手法"为止，不提供任何具体操作步骤。文中提到的部署思路为典型做法，并非特指某一真实客户。

回到最开始那个问题——几个人都能 root 登服务器，出了事怎么查是谁干的。答案不在加固清单里。先把归因做起来：一人一钥、私钥带口令、登录入口收口；再补留痕：sudo 日志记录到能回放、关键路径有执行审计、入口上有会话录制；排在末位的才是改端口、关密码这类加固动作。顺序反了，防护加得再厚，出事那天你手里还是只有一行看不出是谁的 Accepted publickey。

这里也顺带说一句前提：上面每一步都要求你对操作系统有完全的控制权——能改 sshd 配置、能定 sudo 规则、能装内核审计组件、能把日志发到你自己管的机器上。一万网络深耕 IDC 19 年（成立于 2007 年），提供独立服务器租用，机器完全归你自己管，root 权限与登录策略由你自己定；具体配置以官网实时显示为准。