useradd 创建用户默认不创建家目录、不设密码、不指定 shell，需加 -m 和 -s /bin/bash；sudo 权限须显式加入 sudo（debian）或 wheel（rhel）组，且需重新登录生效，严禁修改 uid 为 0。

直接给结论：创建用户 ≠ 自动获得权限，必须显式配置组归属或 sudoers 规则，否则新用户连 sudo 命令都执行不了。

---

useradd 创建用户时必须加 -m 参数

useradd 默认不创建家目录，也不复制默认配置文件（如 .bashrc、.profile），导致用户首次登录后处于“空壳”状态：无家目录、无 shell 初始化、cd ~ 报错、ls 提示权限拒绝。

• 必须显式加 -m 才会创建 /home/username
• 推荐同时指定 shell：-s /bin/bash（避免某些系统默认用 /bin/sh，功能受限）
• 示例：

  sudo useradd -m -s /bin/bash devops

• 验证是否成功：
  • id devops —— 看 UID/GID 和主组
  • ls -ld /home/devops —— 确认目录存在且属主正确

---

sudo 权限不是靠密码，而是靠组成员身份

新用户即使设了密码，也默认完全无法使用 sudo。Linux 不靠“密码对就给 root 权限”，而是靠“是否属于有授权的组”。

• Debian/Ubuntu 系统：授权组是 sudo

  sudo usermod -aG sudo devops

• RHEL/CentOS/Fedora 系统：授权组是 wheel

  sudo usermod -aG wheel devops

• 关键点：
  • -aG 中的 -a（append）不能省——漏掉就变成覆盖原有附加组，可能踢出 docker、adm 等已有权限组
  • 改完组后，用户需**重新登录**（或新开 shell）才能生效，su - devops 不等于“重载组权限”，它只是切换身份，不会刷新当前 session 的组列表
  • 验证：groups 命令应输出含 sudo 或 wheel

---

别直接改 /etc/passwd 把 UID 设成 0

有人为图快，把新用户的 UID 改成 0（即 root 的 UID），以为这样就能“直接 root”：

devops:x:0:1001::/home/devops:/bin/bash

这非常危险：

onewo-rtlinux

Linux 实时编程助手。生成、审查并修改用于周期性控制任务和中断驱动程序的 C 代码。强制实施实时调度策略。

下载

• 多个 UID=0 的账户会让日志、审计、sudo 日志无法区分真实 root 操作
• ls -l 显示所有 UID=0 文件属主都是 root，丧失归属追踪能力
• 某些安全策略（如 SELinux、PAM 模块）会拒绝非 root 用户 UID=0 的登录尝试
• 更糟的是：如果该用户密码被爆破，攻击者就拿到了等效 root 的持久入口

正确做法永远是走 sudo 授权路径，而不是伪造 UID。

---

权限生效后仍执行失败？检查这几个地方

sudo whoami 返回 root 是基础验证，但实际运维中常卡在更细粒度的权限上：

• sudo systemctl restart nginx 失败？可能是 systemd 要求用户在 systemd-journal 组里才能读日志，需追加：sudo usermod -aG systemd-journal devops
• sudo docker ps 报 “permission denied”？得加进 docker 组：sudo usermod -aG docker devops
• 某些脚本依赖 /run/user/UID 目录，而该目录由 pam_systemd 模块在登录时创建——如果用户用 ssh 登录却没启动 user session（比如禁用了 PAM），systemd --user 就起不来

这些都不是“sudo 权限没给全”的问题，而是服务级权限需要独立授予，和 sudo 组无关。

真正容易被忽略的，是组权限变更后不重启登录会话，以及把 UID=0 当快捷方式——这两点一旦出事，排查成本远高于多敲两行 usermod。