★ FEATURED ARTICLE 1. 先把思路理清楚用户管理需要提前设计1.1 从“root 一把梭”到多用户分权拿到一台刚装好的 Debian VPS绝大多数人第一件事是拿 root 密码登进去然后就一直这么用下去。这样省事但也有明显问题root 执行的每一条命令都没有缓冲rm -rf打错一个空格就是灾难日志里所有操作都记在 root 名下出了事根本查不到是谁干的更麻烦的是一旦有第二个人需要登录同事帮你排查、外包做迁移、自己用两个终端就只能共享同一个 root 账号密钥一换所有人都得跟着换。所以只要有“多用户”的需求出现用户管理就会变成刚需。这属于运维流程中的第一环节。新建用户、分配 sudo 权限、离职删号这套动作在整个服务器的生命周期里会反复做几十次。用户和权限没理清楚后面装 Nginx、配数据库、部署应用全都属于把风险放大。核心关键词先说清楚在 Debian VPS 上添加用户、删除用户、授予 sudo 权限本质上就是围绕/etc/passwd、/etc/shadow、/etc/group、/etc/sudoers.d这四个位置做增删改查。搞明白这四个文件的关系你就从“复制粘贴命令”进化到“知道自己在改什么”。这篇文章主要面向三类人刚买 VPS 的新手照着做能把最小权限框架搭起来有一定经验但没系统整理过的开发者能补上删除用户时容易忽略的问题以及需要给团队开账号的人可以直接使用文中的批量脚本和授权模板。1.2 Debian 用户体系里几个绕不开的基础概念很多人卡在“为什么加了组还是没权限”问题通常出在没搞懂 Linux 用户的三个属性UID、主组、附加组。UID 是系统真正认的东西用户名只是给人看的标签。Debian 默认把 UID 100060000 留给普通用户0 是 root1999 是系统账号www-data、systemd-network这些。你可以去/etc/login.defs里看到UID_MIN 1000这样的定义。这也解释了一个常见疑问为什么我新建的用户 UID 从 1001 开始而不是 1000因为装系统时创建的第一个用户已经占了 1000。每个用户有且只有一个主组GID 写在/etc/passwd第 4 字段可以有任意多个附加组记录在/etc/group里。Debian 默认开启USERGROUPS_ENAB yes所以adduser zhangsan会自动建一个同名组zhangsan并把 zhangsan 的主组设成它。这个设计的好处是 umask 配合下用户自己创建的文件不会莫名其妙被别人改。而 sudo 权限这件事Debian 的判定逻辑是sudo 程序去读/etc/sudoers以及/etc/sudoers.d/下的所有文件看当前用户或用户所属的组有没有匹配的规则。所以“给用户 sudo 权限”这句话落到操作上其实只有两种实现——把用户塞进sudo组或者给他单独写一条规则。前者省事后者可控。1.3 三种授权路径先选清楚再动手我在不同场景下会用不同方式先给个对照表你按自己的需求对号入座授权方式具体做法适用场景风险与代价加入 sudo 组usermod -aG sudo 用户自己用、信任的同事、需要完整管理权限拿到全部 root 能力属于“全权委托”sudoers.d 独立规则在/etc/sudoers.d/建文件写规则需要留痕、想给不同人不同权限语法写错会导致 sudo 全线不可用命令白名单用户 ALL(root) /usr/bin/systemctl restart nginx让运维只重启服务、让开发只看日志配不好容易被绕过提权顺便澄清一个 Debian 上特别常见的坑很多网上的教程写usermod -aG wheel 用户那是 RHEL/CentOS 系的习惯。Debian 默认没有启用 wheel 组/etc/sudoers里%wheel那一行是被注释掉的。你在 Debian 上照抄命令不会报错但用户死活拿不到 sudo能排查半天。Debian 的对应组名就叫sudo。2. 动手前必须确认的环境与准备工作2.1 确认版本、登录方式和现有权限Debian 的adduser、sudo默认配置在不同大版本之间有细微差别比如 Debian 12 默认不再预装某些编辑器所以第一步永远是确认自己在什么系统上。cat /etc/debian_version lsb_release -a 2/dev/null uname -m whoami idid这条尤其重要它会告诉你当前账号的 UID、主组和附加组。如果你现在是uid1000(xxx) gid1000(xxx) groups1000(xxx),27(sudo)说明你已经在 sudo 组里了后面很多步骤只是确认。接着确认 sudo 本身装没装。最小化安装的 Debian 镜像是真的可能没装 sudo 的dpkg -l | grep -E ^ii\s(sudo|adduser)\s如果 sudo 没装而你现在是 root直接apt update apt install -y sudo补上。如果你不是 root 又没 sudo那就只能先从控制台用 root 登录处理这一步没有捷径。2.2 备份习惯改任何系统级配置之前先留一份/etc/sudoers是那种“改坏了会让人进不去系统”的文件。我的习惯是每次动它之前先打一份带日期的备份install -m 0440 /etc/sudoers /root/sudoers.bak.$(date %F)注意备份不要放在/etc/sudoers.d/目录里面。sudo 会读取该目录下所有文件名不含.且不以~结尾的文件你把sudoers.bak.20250101放进去里面要是有语法错一样会让 sudo 罢工。放在/root下最安全。还有一个更省心的做法直接在/etc/sudoers.d/里建独立文件永远不去碰主文件。这样主文件的默认规则保持原样出问题时删掉自己那个文件就能回滚。2.3 保命习惯先开第二个 SSH 会话再动手这条听起来啰嗦但它救过我至少三次。原因很直接/etc/ssh/sshd_config里如果有AllowUsers或AllowGroups限制你新建的用户可能压根登不上/etc/sudoers语法写错sudo 会直接拒绝所有请求包括你自己的。所以标准动作是保持当前 root 或已有 sudo 的会话不要关另开一个终端用新用户尝试登录、尝试sudo -l两边都验证通过再关掉旧会话。注意如果你是通过某个面板或网页控制台登录的先确认它有没有“救援模式”或“VNC 控制台”入口。有的话心里更有底因为最坏情况还能从带外通道进去改文件。3. 添加用户adduser 和 useradd 到底该用哪个3.1 adduser交互式添加日常首选Debian 把adduser做成了一个 Perl 封装脚本它内部会调用useradd、passwd、chfn等一串命令把该做的事一次做完。日常手工建号我基本都用它adduser zhangsan执行后会依次问你New password: Retype new password: passwd: password updated successfully Changing the user information for zhangsan Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n]这里有个小技巧后面那五项 GECOS 信息全部直接回车跳过。它们只影响finger显示和邮件头对服务器账号毫无意义填了反而多几个要维护的字段。adduser zhangsan在背后实际做了这些事值得逐条知道在/etc/passwd加一行UID 自动取当前最大值 1在/etc/group建同名组GID 与 UID 一致在/etc/shadow写入密码哈希创建/home/zhangsan权限0755受DIR_MODE影响把/etc/skel下的.bashrc、.profile等模板文件复制进家目录默认 shell 是/bin/bash。如果你不想交互adduser也支持非交互模式加--disabled-password或者配合--gecos adduser --disabled-password --gecos zhangsan--disabled-password的意思是密码字段写!锁定状态此时用户只能用 SSH 密钥登录。这也是我给自动化部署账号建号的常用姿势——服务器账号不设密码只认密钥从源头上消掉暴力破解的可能。3.2 useradd参数化添加脚本和批量场景用它useradd是更底层的命令来自passwd包。它默认什么都不做不建家目录、不设密码、shell 是/bin/sh。所以直接useradd zhangsan之后再登录你会看到一个没有家目录、提示符是$而不是zhangsanhost:~$的怪环境。正确写法是把参数一次配齐useradd \ -m \ -d /home/zhangsan \ -s /bin/bash \ -G sudo \ -c zhangsan ops account \ zhangsan passwd zhangsan逐项解释一下为什么这么写-m创建家目录。不加这个参数家目录不会自动建很多程序比如ssh写authorized_keys会因为目录不存在而失败。-d显式指定家目录路径。虽然默认就是/home/用户名但写出来可读性更好也方便你哪天想把某个账号的家目录放到/data盘上。-s /bin/bash不指定的话默认是/bin/sh在 Debian 上链接到dash不支持[[ ]]、数组这些 bash 特性用户会觉得处处别扭。-G附加组多个用逗号分隔如-G sudo,docker。注意-G是覆盖附加组列表不是追加。这是useradd和usermod最容易混的点。-c注释字段写清楚这个号是干什么的半年后回来看你会感谢自己。passwd zhangsan要单独执行因为useradd不会设置密码。如果你想一步到位用-p传加密后的密码需要先用openssl passwd -6生成哈希HASH$(openssl passwd -6 YourStrongPass) useradd -m -s /bin/bash -p $HASH zhangsan不过说实话密码明文进 shell 历史这件事本身就很不安全history里留着、ps也可能被看到我更推荐建完号立刻用passwd交互设置或者干脆走密钥。3.3 建完号必须马上检查的三件事命令跑完不代表就完了我每次都固定查三项getent passwd zhangsan id zhangsan ls -ld /home/zhangsan第一条看账号是否正确落库getent走的是 NSS比起直接grep /etc/passwd更准确以后万一接了 LDAP 也能查到。第二条看 UID、GID、附加组是不是符合预期。第三条看家目录属主对不对——如果你用useradd -m但之前同名目录已经被别的用户占了useradd会警告但依然继续结果新用户家目录属主是别人的SSH 密钥怎么都写不进去。顺手再做两件小事chage -l zhangsan passwd -S zhangsanchage -l能看密码有效期passwd -S输出zhangsan P 2025-01-01 0 99999 7 -1这种格式第二个字段P表示密码已设、L表示锁定、NP表示无密码。这个字符在排查“为什么这个号登不上”时非常有用。3.4 批量建号给团队开账号的脚本写法如果要给十几个人开号一条条敲显然不现实。我常用下面这种“读文件 循环”的写法把用户名放在一个文本里一行一个#!/usr/bin/env bash set -euo pipefail USERLIST/root/newusers.txt TMPPASS/root/initpass.$(date %s).txt : $TMPPASS while IFS read -r u; do [[ -z $u || $u ~ ^# ]] continue if id $u /dev/null; then echo [skip] $u already exists continue fi p$(tr -dc A-Za-z0-9_#% /dev/urandom | head -c 16) useradd -m -s /bin/bash $u echo $u:$p | chpasswd # 首次登录强制改密码 chage -d 0 $u echo $u $p $TMPPASS echo [ok] $u created done $USERLIST chmod 600 $TMPPASS echo 初始密码记录在 $TMPPASS分发后请立刻删除这个脚本里有几个刻意的设计值得说一下为什么chage -d 0把“最后修改密码日期”设为 0效果是用户下次登录时被强制要求改密码这样临时密码就算被中间人看到也只有一次价值。初始密码写到权限 600 的文件里而不是直接打到屏幕是为了避免密码留在终端回滚缓冲和~/.bash_history里。随机密码用/dev/urandom过滤而不是拼日期是因为基于日期的密码可预测性太强。4. 授予 sudo 权限三条路按需选一条4.1 最省事把用户加进 sudo 组Debian 装完 sudo 之后/etc/sudoers里默认有这么一行#include之外的部分%sudo ALL(ALL:ALL) ALL这行的含义是sudo组的所有成员可以在任意主机上以任意用户和任意组的身份执行任意命令执行时需要输入自己的密码。注意最后一个ALL指的是命令这也是为什么说加入 sudo 组等于全权委托。命令有两种写法效果一样usermod -aG sudo zhangsan # 或者 Debian 风格 adduser zhangsan sudoadduser 用户 组名这个用法很多人不知道它其实就是“把用户加到某个附加组”的简写输出还会很贴心地打印Adding user zhangsan to group sudo ... Done.。这里的-a绝对不能省。usermod -G sudo zhangsan不带-a的含义是“把用户的附加组设置为 sudo”原来在docker、www-data组里的身份会被全部清掉。这个坑我踩过一次一台机器上的部署账号本来在docker组里我给另一个人加 sudo 时手滑漏了-a第二天所有容器操作全部permission denied排查了半小时才想起来是这里。改完之后验证id zhangsan # 输出里应该能看到 groups1001(zhangsan),27(sudo)有个细节值得展开加组之后sudo 立刻就能用但其他基于组的权限需要重新登录才生效。原因是 sudo 每次执行都会通过 PAM 重新读/etc/group而普通进程的组列表是在登录时login/sshd调setgroups写进内核的之后不会自动刷新。所以如果新加的组是docker、libvirt这类你必须让用户退出再登录或者临时用newgrp docker开个子 shell。4.2 更规范在 sudoers.d 下写独立规则给不同的人开不同权限最清晰的做法是一人一个文件。这样谁有什么权限一目了然删权限就是删文件不需要在几百行里找那一行。visudo -f /etc/sudoers.d/zhangsan一定要用visudo -f而不是vim。visudo会在保存时做语法检查写错了直接报错让你重来vim直接保存然后 sudo 全线瘫痪。如果机器上没装vim最小化 Debian 常见visudo会回退到nano也能用。想指定编辑器可以EDITORvim visudo -f ...。文件内容最简版zhangsan ALL(ALL:ALL) ALL拆开看这四个字段第一个是适用对象用户或%组第二个是允许从哪些主机发起服务器场景基本都写ALL第三个是括号里的“可以切换成哪个用户和组”第四个是允许执行的命令。几个高频变体# 免密 sudo自动化脚本常用 deploy ALL(ALL) NOPASSWD: ALL # 只能重启指定服务 ops ALL(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx # 只能看日志不能改 dev ALL(root) /usr/bin/journalctl, /usr/bin/tail # 组级别授权 %devops ALL(ALL) ALL写完之后有个必须做的收尾动作/etc/sudoers.d/下的文件权限必须是0440属主 root。visudo -f新建时通常是对的但如果你用tee或者从别处cp过来权限可能是0644sudo 会拒绝加载并给出sudoers file ... bad permissions的警告。chmod 0440 /etc/sudoers.d/zhangsan chown root:root /etc/sudoers.d/zhangsan visudo -cvisudo -c是全文语法检查输出parsed OK才算真正过关。养成这个肌肉记忆能省掉很多“突然用不了 sudo”的心跳时刻。4.3 最细粒度命令白名单与它的风险给开发同学配“只能重启应用、只能看日志”的权限是命令白名单最典型的用法dev01 ALL(root) NOPASSWD: /usr/bin/systemctl restart myapp, \ /usr/bin/systemctl status myapp, \ /usr/bin/journalctl -u myapp三个技术点必须说清楚命令要写绝对路径。写systemctl而不是/usr/bin/systemctl是无效的sudo 只做字面匹配你写的路径必须和用户实际调用的完全一致。先which systemctl确认路径。参数也是匹配的一部分。journalctl -u myapp和journalctl -u myapp --no-pager是两条不同的规则。想放宽可以用通配符/usr/bin/journalctl -u myapp *但通配符范围要谨慎控制。有些命令天然等于 root shell。这条经验很关键vi、vim、less、more、find、awk、man、tar、python、perl这些在 sudo 白名单里几乎等于给了完整 root。原因很简单sudo vi打开文件后按:!bash就是一个 root shellsudo less输入!bash同理。所以看到“只给用户 sudo less 看日志”这种配置其实等于没限制。我的做法是能包装成固定脚本的就不要开放原始命令。写一个/usr/local/bin/app-restart.sh里面固定systemctl restart myapp然后只授权这个脚本#!/usr/bin/env bash set -euo pipefail systemctl restart myapp systemctl is-active myappdev01 ALL(root) NOPASSWD: /usr/local/bin/app-restart.sh脚本本身的权限要锁死chown root:root /usr/local/bin/app-restart.sh chmod 0755 /usr/local/bin/app-restart.sh如果有人能改这个脚本内容那白名单就形同虚设。这是“最小权限”落地时最容易漏的一环。4.4 免密 sudo什么时候该用什么时候是灾难NOPASSWD用起来确实爽但要想清楚它的边界。它省掉的是“证明你是你”这一步也就是说任何能接触到这个账号的人都自动拥有对应权限。所以自动化部署账号CI 拉代码、重启服务用NOPASSWD是合理的因为本来就没有人坐在终端前交互式管理账号不要开NOPASSWD: ALL人一旦不再需要敲密码误操作的次数会明显上升如果确实需要免密把范围收紧到具体命令而不是ALL。验证配置是否生效最直接的办法是切到那个用户去看他的权限清单su - zhangsan sudo -l输出会精确列出他能执行什么类似User zhangsan may run the following commands on host: (ALL : ALL) ALL如果看到Sorry, user zhangsan may not run sudo on host.说明规则没匹配上。八成是三种情况组名写成了wheel、文件权限不是 0440、或者文件里语法有误导致整个文件被跳过visudo -c会告诉你。还有一个隐蔽的坑sudo -l和实际执行在少数情况下结果不同。因为sudo -l会展开Defaults里的配置如果某处设了Defaults:zhangsan !authenticate之类的条件表现会有差异。排查时以实际执行为准。4.5 用 sudoers 做安全加固的几个选项除了给权限/etc/sudoers.d/还能用来收紧行为。我常用的几条# 记录 sudo 执行的完整命令到独立日志 Defaults logfile/var/log/sudo.log Defaults log_input, log_output # 每次 sudo 都要密码不复用时间戳 Defaults timestamp_timeout0 # 输错密码时给提示而不是干等 Defaults passwd_tries3, badpass_message密码错误请确认后再试timestamp_timeout0这条对共享服务器特别有用。sudo 默认记住密码 15 分钟意味着你 sudo 一次之后旁边的人接手键盘可以直接 sudo不用密码。改成 0 就是每次都要验多敲几次密码换来的是操作可追溯。log_input, log_output会把 sudo 会话的输入输出录到/var/log/sudo-io/占空间但审计价值很高。这个功能默认是关闭的需要先mkdir -p /var/log/sudo-io并设置合适权限否则 sudo 会报错。5. 删除用户userdel 的三个层级与残留清理5.1 动手前先确认这个账号正在干什么删除用户比创建用户更需要谨慎因为删账号不会停止正在运行的进程。一个后台跑了三个月的服务如果是这个用户起的删完账号服务照跑但它的文件全部变成“孤儿”之后出了问题找不到人。所以第一步永远是观察id zhangsan who | grep zhangsan loginctl list-sessions ps -u zhangsan -o pid,ppid,cmdps -u这条能列出该用户所有进程。如果看到有systemd --user、数据库进程、tmux会话之类的先处理进程再删号。如果是正常离职先礼后兵usermod -L zhangsan # 锁定密码 usermod -s /usr/sbin/nologin zhangsan # 禁用 shell 登录 pkill -u zhangsan # 结束其进程 loginctl terminate-user zhangsan # 踢掉 systemd 会话先锁定再删除中间留出观察期是我比较推荐的做法。有些公司的做法是“先锁 7 天确认没人报警再删”能避免“删完才发现某条定时任务靠这个账号跑”的尴尬。5.2 userdel 与 deluser删到什么程度Debian 上有两个删除命令行为差别不小。userdel zhangsan # 只删 /etc/passwd、/etc/shadow、/etc/group 里的条目 userdel -r zhangsan # 额外删除家目录和邮件池userdel -r会尝试删掉/home/zhangsan和/var/mail/zhangsan。但有一个重要前提它会检查家目录里有没有属于其他用户的文件。如果有比如共享目录被挂载进来、或者别人往里面放过东西userdel会拒绝删除目录并报错userdel: zhangsan mail spool (/var/mail/zhangsan) not found userdel: /home/zhangsan not owned by zhangsan, not removing这时候你要么手动确认后rm -rf要么就保留目录只删账号取决于这些外来文件重不重要。不要无脑rm -rf一个报错的家目录尤其是里面有别人数据的时候。deluser是 Debian 的友好封装deluser zhangsan --remove-home deluser zhangsan --remove-all-files deluser zhangsan sudo # 只把用户从 sudo 组移除--remove-all-files会在整个文件系统里查找属于该 UID 的文件并删除比userdel -r彻底得多。这个参数要非常小心它会全盘扫描在数据盘很大的机器上可能跑很久而且一旦删错没法挽回。我给自己的规矩是只在确认这台机器上没有重要共享数据时才用它。5.3 手动清理那些 userdel 不会碰的东西这是全文最有实操价值的部分。userdel只处理账号数据库和家目录下面这些全都要手动看一眼定时任务。用户的 crontab 存在/var/spool/cron/crontabs/用户名。userdel在 Debian 上不会自动删它残留下来的任务会以该 UID 继续执行或者因为找不到用户而报错刷日志。crontab -u zhangsan -r ls -l /var/spool/cron/crontabs/如果用户已经删了、crontab 文件还在直接rm -f /var/spool/cron/crontabs/zhangsan。systemd 单元。检查有没有以这个用户身份运行的服务grep -rl Userzhangsan /etc/systemd/system/ /lib/systemd/system/ 2/dev/null systemctl list-units --all | grep -i zhangsan有的话要么把User改成别的账号要么停掉并禁用该单元。sudoers 里的残留规则。我见过好几次“用户删了但/etc/sudoers.d/zhangsan还在”的情况。这本身不会导致问题用户名不存在规则匹配不上但如果以后有人建了同名账号就会自动继承那份权限——这是个实实在在的安全隐患尤其在批量建号的团队里很容易撞上。ls /etc/sudoers.d/ grep -rn zhangsan /etc/sudoers /etc/sudoers.d/ 2/dev/nullSSH 相关。家目录删了authorized_keys自然没了。但如果用户曾经用过系统级的/etc/ssh/authorized_keys/目录或者AuthorizedKeysFile被改过就要单独清理。其他散落的位置。一次性全查一遍find / -xdev -uid 1001 -ls 2/dev/null find / -xdev -nouser -ls 2/dev/null | head -50第一条按 UID 找用id拿到的旧 UID第二条找“文件属主 UID 在/etc/passwd里不存在”的孤儿文件。-xdev保证不跨文件系统避免扫到挂载的网络盘。注意userdel之后UID 1001 可能被下一个新用户复用所以最好在删除前先跑一次find -uid把清单存下来删完再按清单逐项处理。顺手看一眼/tmp和/var/tmpls -ld /tmp/*zhangsan* /var/tmp/*zhangsan* 2/dev/null临时目录里的文件系统重启会清但会话级别的东西比如 tmux socket、X11 锁文件可能在/tmp里留很久。5.4 删完之后的验证清单我固定跑这四条确认干净getent passwd zhangsan # 应无输出 getent group zhangsan # 应无输出 id zhangsan # 应报 no such user ls -d /home/zhangsan 2/dev/null # 应无输出getent group这条容易被忽略。如果删号时用的是userdel而不是userdel -r或者同名组因为某些原因没被一起删掉会留下一个 GID 悬空的组。以后新建用户时如果 GID 撞上可能会出现文件属主显示成数字 GID 的情况。6. 常见问题与排查技巧实录6.1 高频报错速查表报错或现象真实原因处理方式zhangsan is not in the sudoers file没加入 sudo 组或规则文件未生效id看组visudo -c查语法确认文件权限 0440sudo: parse error in /etc/sudoers.d/xxx near line Nsudoers 语法错visudo -f修正或先mv掉该文件恢复 sudouserdel: user zhangsan is currently used by process 12345还有进程在跑pkill -u zhangsan或先usermod -L锁号adduser: The user zhangsan already exists账号存在getent passwd zhangsan确认要重建则先删用户能登录但没有家目录useradd没加-mmkhomedir_helper zhangsan或手动cp -r /etc/skel/. /home/zhangsan新增组权限不生效组列表在登录时固化退出重新登录或newgrp 组名sudoers file ... bad permissions文件权限不是 0440chmod 0440 /etc/sudoers.d/xxxSSH 密钥登录失败但密码能登.ssh或authorized_keys权限过宽目录 700文件 600属主必须是本人6.2 sudoers 写坏了怎么办这是最需要预案的场景。症状是任何 sudo 命令都报parse error包括你想用 sudo 去修文件的那条命令。这时候分三种情况处理。情况一你还有 root 会话。最简单直接用 root 改mv /etc/sudoers.d/broken /root/broken.bak visudo -c情况二没有 root 会话但有带外控制台。从 VPS 面板的 VNC/救援控制台用 root 登录操作同上。情况三完全没有 root 通道。那就只能走单用户模式或救援系统把根分区挂载为可写然后修改文件。这个过程每家主机商的控制台操作路径不同但本质都是进救援环境、mount /dev/vda1 /mnt、chroot /mnt、修文件、重启。正因为存在情况三我的建议一直是主 sudoers 文件一行不改所有自定义规则放/etc/sudoers.d/每次保存前visudo -c。这套习惯能让“写坏”这件事的概率降到接近零。6.3 权限边界上几个容易被忽略的细节sudo 的时间戳是按“终端”记的不是按“用户”。默认配置下你在一个 SSH 会话里 sudo 过同用户另开一个会话还是要重新输密码。想改成全局的话是Defaults !tty_tickets但我不建议——按终端隔离反而更安全。su和sudo的差别不只是“要不要密码”。su - root需要知道 root 密码而且切过去之后所有操作都记在 root 名下sudo需要的是自己的密码日志记的是“谁用什么命令”。所以从审计角度应该禁用 root 直接登录全部走 sudo。在/etc/sudoers.d/里用%前缀代表组用#前缀代表 UID。比如#1001 ALL(ALL) ALL是按 UID 授权。UID 授权的好处是不怕改名坏处是UID 可能被复用——删掉的 1001 号用户新建用户时可能又拿到 1001等于自动继承了权限。所以我从不按 UID 授权只按用户名或组名。审计日志的位置。Debian 上 sudo 的默认记录在/var/log/auth.loggrep sudo /var/log/auth.log能看到每次执行的完整命令和发起用户。如果用了Defaults logfile则写到指定文件。做安全排查时这两个位置都要看。7. 我在实际运维里的几条固定习惯最后分享几个我踩过坑之后固化下来的做法都是很琐碎但省钱省时间的。给每个需要用 sudo 的人单独建号绝不共享。共享账号短期内省事一旦出事就是“所有人都没责任”。而且人一走你都不知道该不该改密码。新建用户一律先配密钥再给 sudo。顺序很重要先ssh-copy-id验证能登录再usermod -aG sudo。倒过来做万一密钥配错了你就多了一个能 sudo 但登不进去的账号还得回头收拾。/etc/sudoers.d/里的文件名统一用“用户名.conf”格式。因为 sudo 会跳过含.的文件所以别用zhangsan.bak、zhangsan.20250101这类名字去做“备份”它们会被直接忽略你以为备份生效了其实没有。要备份就cp到/root下。给自动化账号单独设一个组别混进 sudo 组。比如建个deploy组在/etc/sudoers.d/deploy里只开放那几条部署命令。这样即使某台机器上的 CI 密钥泄露攻击者也只能重启服务拿不到 shell。每季度花十分钟复查一遍。getent group sudo看名单、ls /etc/sudoers.d/看规则文件、grep -c sudo /var/log/auth.log看有没有异常调用。三分钟能做完的事能挡掉大部分“幽灵账号”问题。至于删除用户这件事我的体会是删除账号那一刻只完成了 60%剩下的 40% 在清理残留。crontab、systemd 单元、sudoers 文件、孤儿文件这四样每样都单独查一遍才算真正删干净。我现在的习惯是先usermod -L锁定观察一周确认没人报警再走完整删除流程加清理清单虽然慢一点但从没出现过“删完才发现某个定时备份任务停了三个月”这种事。
阅读完成 · 觉得有帮助？
