Debian 12 VPS 用户添加、sudo 授权与删除避坑指南-北京尧图网络

手上刚拿到一台 Debian 12 的 VPS第一件事往往不是装环境而是处理账户把 root 收起来建一个自己的普通用户再给它配上 sudo 权限。听起来是三行命令的事但我在实际维护中见过太多因为这几步没做对而返工的案例——有人把自己锁在系统外面有人改坏了 sudoers 导致所有人失去提权能力还有人删了用户却发现家目录、crontab、SSH 密钥全留在原地。这篇就把 Debian VPS 上用户的添加、sudo 权限的授予、用户的删除这三个动作拆开讲透包括每条命令背后的取舍、参数怎么定、出错怎么救。无论你是第一次碰 Linux 服务器还是从别的发行版迁过来下面这些细节都值得照着过一遍因为账户和权限是所有后续运维的地基地基歪了后面装什么都白搭。1. 先把用户与权限这套模型捋清楚1.1 Debian 的账户体系到底分了几层Debian 的用户不是平铺的它按 UID 分了几个区间理解这个区间划分能帮你避开很多为什么这个用户怪怪的的困惑。UID 0 是 root全系统唯一UID 1 到 999 是系统账户比如www-data、systemd-network、sshd这些账户通常nologin只用来跑服务不给人登录UID 1000 开始才是普通人类用户Debian 装系统时创建的第一个用户默认就是 1000。这套划分的实际意义在于你手动加人的时候adduser会自动挑一个 ≥1000 的可用 UID而如果你用useradd且忘了指定某些情况下拿到的是系统区间内的号后面跑一些需要用户命名空间或者容器映射的服务就会报奇怪的权限错误。所以我加人之后一定会用id确认一遍id deploy # uid1001(deploy) gid1001(deploy) groups1001(deploy),27(sudo)id输出的三个字段分别对应UID、主组 GID、以及该用户所在的全部组。这里要强调一个初学者最容易混淆的点Linux 用户有一个主组但可以有任意多个附加组。文件权限里的组匹配匹配的是主组加附加组的并集不是只看主组。usermod -aG里的-a就是 append 的意思不加-a会把你原有的附加组全部冲掉——这是新手最容易造成的生产事故之一我从 RHEL 时代就见过有人手一抖把某个用户的 sudo 组挤没了然后那位同事再也提不了权。账户信息的落盘位置也得心里有数/etc/passwd存基本信息用户名、UID、GID、家目录、登录 shell/etc/shadow存密码哈希和过期策略只有 root 可读/etc/group存组和成员/etc/gshadow存组密码。这四个文件是配套的只用vipw、vigr这类专用命令或者adduser/usermod这类封装工具去改直接vim编辑/etc/passwd是自找麻烦。为什么不建议日常用 root 干活理由有三条都很实在。第一root 的误操作没有兜底rm -rf在 root 手里和在普通用户手里是完全不同的两个结局。第二多人协作时你没法追责所有操作都是 root 干的日志里看不出是谁。第三也是很多人忽略的VPS 一旦暴露在公网SSH 端口上的暴力尝试几乎全是冲着root这个用户名来的把 root 的登录方式关掉你就直接过滤掉了绝大部分无效攻击流量。1.2 sudo 和 su 的差别以及为什么我几乎不用 susu和sudo都能让你获得更高权限但机制完全不同选错了会让后续维护很难受。su的本质是切换到另一个用户它要求你输入目标用户的密码。想切 root就得知道 root 密码。而sudo的本质是以另一个用户的身份执行某条命令它要求你输入自己的密码然后去/etc/sudoers里查你有没有资格这么做。这个差别带来的直接后果是Debian 在安装阶段如果设置了普通用户密码root 账户默认是没有密码的/etc/shadow里 root 那一行是*或者!这意味着su -根本进不去会直接报认证失败。这是无数人第一次登 Debian VPS 时踩的坑——他们习惯性地敲su输密码然后一脸茫然。正确姿势是sudo -i或者sudo su -。两条命令的效果也有细微差别值得记住sudo -i # 启动一个 root 的登录 shell加载 root 的完整环境变量cwd 切到 /root sudo -s # 启动一个 root 的非登录 shell保留当前环境变量cwd 不变 sudo su - # 等价于先 sudo 拿到权限再 su 成 root 登录 shell能跑通但不优雅 sudo -u www-data -s /bin/bash # 切成任意指定用户日常我更推荐sudo -i环境干净PATH走的是secure_path不会出现普通用户 PATH 里有个同名程序把系统命令劫持了这种事。sudo还有几个实用的附带能力是su给不了的一是sudo -l可以列出当前用户被允许执行哪些命令排查权限问题时非常好用二是sudo -k可以立刻清掉缓存的凭证让下一次提权重新要密码三是所有 sudo 操作都会写进/var/log/auth.log出问题能回溯到具体是谁、在什么时间、跑了什么命令。做运维的可审计性比方便重要得多。1.3 组是权限的分发单位别直接往人身上挂权限我的原则很简单权限永远授予组人只往组里放。原因在于人是要走的组是稳定的。如果直接把某条规则写在 sudoers 里指向用户名zhangsan等他离职你得记得去删规则而如果规则指向%ops组只需要把人从组里移出去就行规则本身可以长期保留。Debian 上有几个组值得记住组名作用备注sudo成员可通过 sudo 提权到 rootDebian 默认在 sudoers 中已配置adm可读/var/log下的系统日志排查问题常用但不给提权能力systemd-journal可读journalctl全部日志配合adm使用www-dataWeb 服务运行账户一般不给登录 shellusersDebian 默认的普通用户组基本无实际权限含义这里必须提醒一句从 RHEL/CentOS 迁过来的人RHEL 系用的是wheel组而 Debian 用的是sudo组。Debian 的 sudoers 里默认只有%sudo ALL(ALL:ALL) ALL这一行没有 wheel。你把用户加进 wheel看起来命令执行成功了但一点权限都没有然后你会在sudo -l里看到user is not allowed to run sudo浪费半小时。想确认当前系统到底认哪个组直接看配置grep -E ^\s*% /etc/sudoers2. 动手前的三条保命准备2.1 先确认你还有第二条进得去的路这一条是我用血换来的。改 SSH 配置、改 sudoers、删用户这三类操作都有概率把你自己关在门外。所以在动手之前必须确认至少还有一个会话能进系统。最稳的做法是开两个 SSH 终端窗口一个用来操作另一个保持登录状态不动只是挂着。这样万一你改坏了配置操作窗口断开了那个挂着的窗口还在你可以从那里回滚。如果你用的是带控制台功能的服务商那更好网页端的 VNC 控制台是最后的救命绳理论上不依赖 sshd 服务即使 sshd 起不来也能进。另外建议在做任何危险操作前先确认 root 的密码通道是可用的或者至少确认你当前的非 root 用户已经能 sudosudo -v # 刷新并验证 sudo 凭证是否可用 sudo whoami # 应该输出 root这两条命令跑不通就先别往下做了先把你自己的提权路径打通。2.2 备份 sudoers并且改完必验语法/etc/sudoers是个语法非常严格的文件一个逗号放错位置整个文件就失效失效的后果是所有人包括 root 都无法 sudo。听起来好像 root 还能用确实 root 本身不需要 sudo但你如果已经按最佳实践禁用了 root 直接登录那你就真的进不去了。我的固定动作是三步# 第一步备份带时间戳 sudo cp -a /etc/sudoers /etc/sudoers.bak.$(date %F-%H%M) # 第二步只用 visudo 编辑它会做语法检查 sudo visudo # 第三步改完做一次显式校验 sudo visudo -c # 正常输出/etc/sudoers: parsed OKvisudo的价值不只是帮你打开文件它在保存时会先解析一遍语法错误会直接拦下来并提示你要保存吗你选放弃就什么都没改。但要注意一个坑visudo只校验主文件不校验/etc/sudoers.d/下的 drop-in 文件。也就是说你在子文件里写错了visudo是察觉不到的等你退出才发现 sudo 坏了。所以子文件一定要单独校验sudo visudo -c -f /etc/sudoers.d/ops # /etc/sudoers.d/ops: parsed OK注意如果 sudoers 已经坏了而你又进不去 root可以尝试用pkexec visudo需要 polkit 配置或者通过服务商的控制台进单用户模式修复。这个代价很高所以养成改前备份、改后校验的习惯比学会修复更重要。2.3 drop-in 目录的两个隐形规则/etc/sudoers.d/这个目录的设计意图是不要动主文件把自己的规则单独放好处是升级系统时不会被覆盖也方便审计。但它有两个隐形规则不知道就会踩坑第一文件名不能带点.也不能以~结尾。默认的#includedir /etc/sudoers.d会跳过包含.的文件。这本来是防止编辑器备份文件比如ops.conf~、ops.bak被误加载但很多人习惯用.conf后缀命名结果写得好好的规则一条都不生效。第二权限必须是0440属主必须是 root:root。sudo 加载时会检查权限不对就直接忽略这一个文件不是报错退出是静默忽略你会以为规则没生效但找不到原因。sudo chmod 0440 /etc/sudoers.d/ops sudo chown root:root /etc/sudoers.d/ops ls -l /etc/sudoers.d/顺手养成一个习惯改完 drop-in 后用sudo -l -U 目标用户名验证一下最终生效的权限集合这比读配置文件猜要靠谱得多。3. 添加用户从一条 adduser 到能安全登录3.1 adduser 和 useradd 的取舍Debian 系统上同时存在这两个命令名字像但完全不是一回事这点跟 RHEL 系很不一样容易搞混。useradd是底层命令来自 shadow 包行为非常沉默不建家目录、不复制/etc/skel里的初始配置文件、不提示设密码、默认 shell 是/bin/sh。你得自己把参数补全sudo useradd -m -s /bin/bash -c deploy account -G sudo deployadduser是 Debian 特有的 Perl 封装脚本交互式、体贴自动建家目录、自动复制/etc/skel、交互式让你设密码、自动创建同名主组、默认 shell 是/bin/bash。日常加我用adduser脚本化批量加我用useradd带全参数。sudo adduser deploy执行后它会连问几轮密码、确认密码、全名、房间号、工作电话、其他信息后面四项直接回车跳过就行。密码那一步如果密码强度不够它会警告但允许你第二次确认强行通过——我的建议是别强行通过用一个长度足够、混合大小写数字符号的密码或者直接跳过密码改用密钥登录下面会讲。有几个参数值得提前想清楚--uid 1500手动指定 UID方便多台机器统一后面做 NFS 或者 rsync 权限映射时省事。--shell /bin/bash默认就是 bash但如果你的系统在某些镜像上默认是/bin/sh显式指定更保险。--home /data/deploy把家目录放到数据盘适合磁盘分区的场景。--disabled-password只建账户不设密码纯密钥登录时用比设一个随机密码更干净。3.2 密码设置的两条路交互与非交互交互式设密码最直观sudo passwd deploy它会让你输两遍并且根据密码质量给出提示。这里有个经验Debian 默认装了libpam-pwquality有些精简镜像没有会对弱密码做拦截。如果你在自动化脚本里被这个拦住可以在/etc/pam.d/common-password里调minlen和minclass但我不建议为了省事把强度要求调到最低服务器密码泄露的代价太高。非交互式的场景比如用配置管理工具批量建号用chpasswdecho deploy:某个足够复杂的密码 | sudo chpasswd注意这条命令会把明文密码留在 shell 历史和进程列表里生产环境应该用chpasswd的 stdin 配合文件描述符或者干脆跳过密码只用密钥。密码策略这块chage是主力工具sudo chage -l deploy # 查看当前策略 sudo chage -M 90 -W 7 deploy # 90 天强制改密提前 7 天提醒 sudo chage -E 2026-01-01 deploy # 设置账户到期日临时账号必备 sudo chage -E0 deploy # 立即锁定账户比删除温和chage -E0这个技巧值得单独说如果某个账号只是暂时不用比如同事休假、外包项目暂停直接删掉再重建成本高用-E0把账户置为过期登录会被拒绝但一切数据保留恢复时chage -E -1 deploy就回来了。这比usermod -L更彻底因为-L只是给密码前面加个!如果对方用的是密钥登录照样能进。3.3 把公钥塞进去让密码登录彻底退休密码登录是公网 VPS 最大的风险源。我的标准做法是新用户建好后第一件事就是配好密钥然后关掉密码认证。生成密钥对在你自己的本地机器上做不要登到服务器上生成ssh-keygen -t ed25519 -C deploylaptop -f ~/.ssh/id_ed25519_deploy选 ed25519 而不是 RSA 的理由密钥长度短公钥才 68 字节、签名速度快、抗侧信道攻击现代 OpenSSH 全支持。RSA 至少要 3072 位才够看公钥又长又难贴。如果你的环境里还有很老的系统才考虑退回rsa -b 4096。把公钥送上去最省事的是ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519_deploy.pub deploy服务器地址它会在服务器上自动创建~/.ssh权限 700、把公钥追加进~/.ssh/authorized_keys权限 600。如果服务器上没装ssh-copy-id有些精简系统确实没有手动来# 本地执行把公钥内容推过去 cat ~/.ssh/id_ed25519_deploy.pub | ssh deploy服务器地址 \ mkdir -p ~/.ssh chmod 700 ~/.ssh cat ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys手敲模式下最容易出问题的是权限。OpenSSH 对权限极其敏感~/.ssh不是 700、authorized_keys不是 600、或者家目录本身对 group/other 有写权限sshd 就会拒绝使用这个密钥然后在服务端日志里丢一句含糊的Authentication refused: bad ownership or modes。所以配完务必检查chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 755 ~ # 家目录不能是 777 或 group 可写 ls -ld ~ ~/.ssh ~/.ssh/authorized_keys密钥验证通了之后再动 sshd 配置顺序不能反。改/etc/ssh/sshd_configPubkeyAuthentication yes PasswordAuthentication no PermitRootLogin prohibit-password KbdInteractiveAuthentication no UsePAM yes MaxAuthTries 3 LoginGraceTime 20PermitRootLogin我一般用prohibit-password而不是no区别是前者允许 root 用密钥登录应急通道后者彻底禁止。如果你的服务商控制台足够可靠no更干净如果依赖 root 密钥做应急prohibit-password是务实的选择。改完必须做语法检查再 reload绝对不要 restart 赌一把sudo sshd -t # 语法检查无输出即通过 sudo systemctl reload ssh # Debian 上服务名是 ssh不是 sshd sudo systemctl status ssh注意Debian 的 sshd 服务单元叫ssh而进程名叫sshd。systemctl restart sshd在某些版本上会报 unit not found别慌用ssh就对了。还有一个很多人不知道的小技巧reload不会断开现有连接restart会。所以在改 sshd 配置时永远用reload然后保持当前会话不关另开一个新窗口测试能否登录测试通过再关旧窗口。这个习惯能救你无数次。4. 授予 sudo 权限的四条路按场景挑4.1 加进 sudo 组99% 的场景到这就够了最标准、最不容易出错的方式就是把用户加进sudo组sudo usermod -aG sudo deploy-aG里的-a千万别漏。漏了就是usermod -G sudo deploy效果是把 deploy 的附加组重置为只有 sudo他原来在adm、docker、www-data里的成员身份全部消失。这种事故的排查成本很高因为用户只会说我某个功能突然不能用了你得一个个组去比对。加完验证groups deploy # deploy : deploy sudo id deploy sudo -l -U deploy # 以 deploy 的身份列出可执行的命令sudo -l -U这个用法很实用root 可以直接查看任意用户的 sudo 权限不用切过去。输出里会明确列出(ALL : ALL) ALL说明这个用户可以通过 sudo 执行任何命令。改完组权限后有个细节用户需要重新登录才生效。因为组成员关系是在登录时加载到进程凭证里的已经登录的会话不会自动刷新。如果不想让人掉线可以用newgrp sudo在当前 shell 里临时切换但这只影响当前 shell 及其子进程。顺带说一句反向操作如果某个用户需要临时失去 sudo 权限但保留账户用sudo deluser deploy sudo或者gpasswd -d deploy sudo比改 sudoers 干净。想恢复就再usermod -aG sudo。4.2 独立 drop-in 文件需要写备注和限定范围时当你要给的不只是全权限而是有条件的权限时就不该往sudo组里塞了应该写独立的规则文件。sudo visudo -f /etc/sudoers.d/ops-deploy内容示例# 运维账号允许全权限但密码凭证 15 分钟后失效 Defaults:deploy timestamp_timeout15 deploy ALL(ALL:ALL) ALL # 日志审计让这个用户的 sudo 操作单独记一份 Defaults:deploy logfile/var/log/sudo-deploy.logtimestamp_timeout是 sudo 的凭证缓存时间默认 15 分钟。有些发行版默认 5 分钟有些甚至是-1永不过期等于一次提权终身有效非常危险。显式指定成 15 分钟是我认为比较平衡的值连续操作不烦人离开工位后窗口期又不会太长。logfile这个参数在做合规审计时很有用它会把该用户的所有 sudo 命令单独记一份格式包含时间、用户、终端、工作目录、完整命令行。比起在/var/log/auth.log里翻独立文件查起来快得多。写 drop-in 的时候语法上有几个点要留意Defaults后面跟用户名或组名限定作用域格式是Defaults:用户名参数冒号后面不能有空格。User_Alias、Host_Alias、Cmnd_Alias这些别名定义要在使用之前。每条规则的格式是用户主机(切换到谁:切换到哪个组) 命令主机字段写ALL就行本地机器场景下没意义。写完后必做两件事sudo visudo -c -f 文件名校验chmod 0440加chown root:root定权限然后sudo -l -U deploy验证生效。4.3 命令白名单只让某个人重启服务这是 sudo 真正体现价值的地方。假设有个同事需要偶尔重启 Web 服务、看日志、清理缓存但你绝不希望他能改系统配置或者删数据那就给他精确到命令的权限# 定义命令别名方便复用和维护 Cmnd_Alias WEB_OPS /usr/bin/systemctl restart nginx, \ /usr/bin/systemctl reload nginx, \ /usr/bin/systemctl status nginx, \ /usr/bin/journalctl -u nginx *, \ /usr/bin/rm -rf /var/cache/nginx/* # 只允许在特定主机上执行这些命令不需要密码 opsuser ALL(root) NOPASSWD: WEB_OPS几个细节值得展开第一命令必须写绝对路径。sudo 不认systemctl只认/usr/bin/systemctl。不确定路径就用command -v systemctl查。写成相对路径的话sudo 会拿secure_path去解析但一旦解析结果和你预期不一致比如系统里装了多个版本权限边界就破了。第二参数能不能通配要谨慎。systemctl restart nginx是精确匹配用户多敲一个空格都不行写成systemctl restart *就放开了所有服务等于给了重启任意服务的能力。通配符*在 sudo 里匹配的是任意字符序列包括空格和斜杠所以rm -rf /var/cache/nginx/*这条其实有风险——理论上能被构造成删别的目录。更稳的做法是用sudo的引号精确匹配或者干脆给一个专门的脚本用脚本内部做参数校验。第三白名单不是沙箱。这一点必须说透只要你给了某条命令的 root 权限而这个命令本身具备执行任意程序的能力比如vim、less、find、tar、systemctl的某些子命令那用户就能借它逃逸到完整的 root shell。经典例子是sudo vim然后:!bash。所以给白名单之前先问自己这条命令有没有 shell escape 的能力如果有那这个限制就只是形式上好看实质上等于给了全部权限。第四NOPASSWD要不要给。给的好处是自动化脚本能跑通脚本没法交互输密码坏处是拿到这个账号就等于拿到对应命令的 root 权限不需要二次确认。我的判断标准是只读命令status、journalctl、cat可以免密写操作命令restart、rm尽量不要免密除非它是被 CI 系统调用且账号密钥受严格管控。4.4 免密 sudo方便与风险的临界点NOPASSWD: ALL这种写法我在一些教程里见过说这样方便。方便是真的风险也是真的任何拿到这个账号 shell 的人直接就拥有完整 root 权限连密码都不用猜。如果这个账号还允许密码登录那基本等于把 root 密码贴在公网上。如果确实有免密需求比如自动化部署、容器内提权我建议把范围压到最小# 只对特定几条命令免密 deploy ALL(root) NOPASSWD: /usr/bin/docker, /usr/bin/systemctl restart myapp # 或者用 Defaults 全局压缩免密的场景 Defaults:deploy !requiretty关于requiretty这个选项在 RHEL 系默认开启Debian 系默认关闭。它的作用是强制 sudo 必须在一个真实终端里运行防止被脚本滥用。Debian 上不用管它但如果你写跨发行版的配置显式写上Defaults !requiretty能让行为一致。还有一个容易被忽略的加固点Defaults secure_path。Debian 默认的 sudoers 里有这么一行Defaults secure_path/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin它的作用是让 sudo 执行时使用一套固定的PATH而不是继承用户的PATH。为什么要这样因为如果用户能在自己的PATH里塞一个假的ls然后sudo ls那这个假的ls就以 root 身份跑起来了。secure_path堵的正是这条路。不要为了图方便把它删掉。5. 删除用户删干净比删掉难5.1 deluser 和 userdel 的差别跟添加用户一样删除也有两套命令。userdel是底层命令deluser是 Debian 的封装。sudo deluser deploy # 只删账户保留家目录和邮件 sudo deluser --remove-home deploy # 连家目录和邮件一起删 sudo deluser --remove-all-files deploy # 连系统里所有属于该 UID 的文件都找出来删userdel对应的是sudo userdel deploy # 只删 /etc/passwd、/etc/shadow、/etc/group 里的条目 sudo userdel -r deploy # 同时删家目录和邮件池--remove-all-files这个选项要慎用。它会在整个文件系统里按 UID 搜索并删除文件包括/tmp、/var/tmp甚至数据盘上属于这个 UID 的文件。如果这个 UID 被复用比如你删了 UID 1001 的账号新建的账号又拿到 1001那新账号的文件可能被误删。所以我的做法是删除前先固定 UID不轻易复用/etc/login.defs里的UID_MIN可以调高或者干脆在删之前记录一下 UID。5.2 那些不会自动消失的残留这是删除用户最容易出问题的地方。账户条目删了但下面这些东西还在第一正在运行的进程。如果这个用户还有进程在跑比如一个tmux会话、一个后台脚本userdel会报userdel: user deploy is currently used by process 12345直接失败。正确顺序是先杀进程再删用户sudo pkill -u deploy sudo pkill -9 -u deploy # 顽固进程补一刀 # 或者用 loginctl 清理会话 loginctl list-sessions loginctl terminate-user deployloginctl terminate-user比pkill更彻底它会清掉该用户的所有会话、systemd user 实例、以及由 systemd 管理的临时资源。第二crontab 和 systemd timer。用户级 crontab 存在/var/spool/cron/crontabs/用户名userdel不会删它。残留的 crontab 在极端情况下UID 被复用会被新用户继承执行这是个真实存在的安全隐患。sudo crontab -r -u deploy # 删用户的 crontab sudo ls /var/spool/cron/crontabs/ # 确认 ls /home/deploy/.config/systemd/user/ # 用户级 systemd 单元第三authorized_keys 和 SSH 相关文件。这些在~/.ssh里如果没加-r或--remove-home它们会原地不动。如果家目录被保留下来给新用户用那新用户就直接继承了旧用户的登录密钥——这是极其危险的。所以家目录要么一起删要么检查一遍~/.ssh清干净。第四sudoers 里的规则。如果之前给这个用户写过 drop-in 文件userdel不会碰/etc/sudoers.d/。虽然指向已删除用户的规则通常不生效sudo 会忽略找不到用户的规则但留着是噪音也可能在未来 UID/用户名复用时出问题。sudo grep -rl deploy /etc/sudoers.d/ # 找到后删除对应文件 sudo rm /etc/sudoers.d/ops-deploy第五文件和目录的属主。系统里可能还有一堆文件属主是已删除的 UIDls -l会显示成数字而不是用户名。这些文件需要重新归属# 找出所有属于该 UID 的文件 sudo find / -xdev -uid 1001 -ls 2/dev/null # 改归属到新用户 sudo chown -R newuser:newuser /data/shared-xdev参数很重要它让find不跨文件系统避免扫到挂载的 NFS 或者大容量数据盘上浪费时间。先用-ls看清单确认没问题再-exec chown或-delete。第六mail spool 和 at 任务。/var/mail/deploy、/var/spool/cron/atjobs/里也可能有残留。这些不常见但值得一查。我个人的删除检查清单是这样的检查项命令活跃进程ps -u deploy登录会话loginctl list-sessionscrontabcrontab -l -u deploysudoers 规则grep -r deploy /etc/sudoers.d/遗留文件find / -xdev -uid 1001SSH 密钥ls -la /home/deploy/.ssh/6. 常见问题速查与日常维护6.1 报错对照表下面这些是我这些年反复遇到的报错配上排查思路遇到时直接对号入座。报错信息原因解决user is not in the sudoers file. This incident will be reported.用户不在任何一个有 sudo 权限的组里或者 sudoers 里没有对应规则usermod -aG sudo 用户名或写 drop-in 规则sudo: command not found精简镜像没装 sudoapt update apt install sudo需 root 或 suAuthentication failuresu时Debian 默认 root 无密码改用sudo -i或给 root 设密码不推荐sudo: no valid sudoers sources found, quittingsudoers 文件权限或属主错误chmod 0440 /etc/sudoers chown root:root /etc/sudoerssudo: /etc/sudoers.d/xxx is mode 0644, should be 0440drop-in 文件权限不对chmod 0440修正Permission denied (publickey)~/.ssh或authorized_keys权限过宽chmod 700 ~/.ssh、chmod 600 authorized_keysuserdel: user X is currently used by process N该用户还有进程在跑pkill -u X或loginctl terminate-user Xadduser: The user X already exists用户名冲突getent passwd X确认换名或先删旧号sudo: sorry, you must have a tty to run sudosudoers 里有requiretty加Defaults !requirettyusermod: user X does not exist用户名拼错或账户已在上一步被删getent passwd X查证补充两个不在表里但很典型的改完 sudoers 后所有人都提不了权怎么办。这时候 root 本身不需要 sudo如果你还有 root 的登录方式密钥或者控制台直接登进去用pkexec visudo或者在单用户模式挂载文件系统修复。如果连 root 都进不去只能走服务商控制台进 recovery 模式mount -o remount,rw /然后恢复备份。这个流程一定要提前演练一次别等真出事才现学。新加的用户登录后提示Could not chdir to home directory。说明家目录不存在或者权限不对。检查/etc/passwd里该用户的家目录路径是否真实存在不存在就mkdir然后用chown -R 用户名:主组家目录修正。用useradd忘了-m就会这样。6.2 我固定会做的几项巡检账户和权限这种东西出事之前毫无征兆出事之后就是大麻烦。所以我会固定做几项检查频率不高但每次都能发现点东西。第一定期看谁有 sudo 全权限。命令很简单但能查出意外的授权getent group sudo输出里如果出现了你不认识的用户名就要查清楚是谁加的、什么时候加的。多人协作的环境下这个列表很容易失控。第二看最近的提权记录。Debian 的 sudo 日志在/var/log/auth.log较新版本可能已被 journald 接管sudo grep -i sudo: /var/log/auth.log | tail -50 journalctl -u ssh --since 1 day ago | grep -i accepted\|failed后一条能看出有没有人在暴力试密码。如果failed的行数异常多而且来源 IP 集中在某几个段基本可以确认是扫描。这时候除了关掉密码登录还可以考虑装个 fail2ban 做自动封禁或者用iptables/nftables做来源限制。第三检查空密码账户和异常 UID。这两个是经典的后门特征sudo awk -F: ($2 ) { print $1 有空密码 } /etc/shadow sudo awk -F: ($3 0) { print $1 的 UID 是 0 } /etc/passwd第二条尤其重要UID 为 0 的账户不止 root 一个任何 UID 为 0 的账户都有完整 root 权限即使用户名不叫 root。这是入侵者最喜欢留的后门形式之一。第四确认账户策略。长期不用的账户应该锁定或者过期sudo lastlog # 每个账户最后一次登录时间 sudo last | head -20 # 最近登录记录 sudo chage -l 用户名 # 密码和账户的过期策略lastlog输出里的**Never logged in**是重点一个建了三周从来没登录过、但你并不记得为什么存在的账户值得追查来源。还有个小习惯我觉得挺值在/etc/sudoers.d/的每个文件顶部写一行注释记下谁、什么时候、为什么加的这条规则。三个月后你回头看没有这条注释的话你完全想不起来当时为什么要给某个人开放某个命令。实际操作中我的体会是用户管理和权限管理真正难的从来不是记住几条命令而是理解每一条命令的副作用边界。usermod -aG少个-a会冲掉附加组userdel不加-r会留下可被继承的家目录visudo不校验 drop-in 会让规则静默失效NOPASSWD图省事会把限制变成摆设。这些坑的共同点都是命令成功了但结果不是你想要的。所以每敲一条改权限的命令先花三秒确认它只改你想改的那一部分然后在另一个窗口验证一遍这个习惯比任何工具都管用。

Debian 12 VPS 用户添加、sudo 授权与删除避坑指南

相关推荐

昇腾NPU原生Numpy库ASNUMPY性能优化与应用解析

昇腾NPU原生Numpy库ASNUMPY：AI计算新范式

边缘计算与云端方案在温湿度监测中的对比与实践

更多资讯

基于Hadoop+Spark的智能租房推荐系统架构与实现

Java社区老年人健康管理系统开发实践

马尾辫怎么扎好看不伤发？从高度、脸型到发圈选择的完整指南

企业智能体工程实践：从概念到落地的核心要素

Multisim 14.0安装授权与仿真验证避坑指南

OpenMontage：开源智能粗剪工具，让视频剪辑告别体力活

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？