做运维这些年,我越来越有个体会:Linux 服务器上最能体现管理功底的,不是搭集群、搞架构,反而是“新增一个用户”这种不起眼的小事。原因很简单,一个新用户从创建到能用,牵扯到账号权限、Shell 环境、文件归属、安全基线、运维规范,任何一个环节偷懒,都会在后面变成半夜三更的报警消息。
很多刚接触 Linux 的朋友觉得,创建用户嘛,无非是 useradd 加个密码就完事。但真正从“建号”到“能干活”,中间还有一整套初始化工作。这篇文章我就从实际运维的角度,把 Linux 新用户创建及初始化这件事拆开揉碎,从需求规划、命令细节、环境配置、安全加固,到常见故障排查,一次讲透。不管是刚入行的运维新人、偶尔需要管服务器的后端开发,还是准备 Linux 面试的求职者,这都是一份可以直接照着操作的参考。
1. 先想明白:新建用户前要定哪些事
1.1 用户类型与命名规范
动手敲命令之前,先搞清楚你要建的是什么类型的账号。 Linux 里的用户大体分三类:
- 超级用户:UID 为 0,就是 root,拥有系统一切权限。
- 系统用户:也叫伪用户,UID 通常在 1-999(不同发行版有差异),一般给服务进程用,比如 nginx、mysql、sshd 都有自己的系统账号。它们通常不能登录,也没有家目录或家目录在 /var/lib 下。
- 普通用户:UID 从 1000 开始分配,就是给人用的,有独立家目录、可以登录 Shell、适合日常操作。
命名规范这件事,小团队可能无所谓,但稍微正规点的公司都有约定。我建议规则越简单越好,比如用姓名拼音全称或首字母+工号:zhangsan、lisi、wangwu01。千万别用 admin、test 这种一看就随便起的名字,也别用中文、特殊字符,否则后面写脚本、配 sudo、做审计都会很痛苦。
另外要提前定好 UID 分配策略。如果你的服务器要跟 NFS、备份系统、日志采集系统对接,账号 UID 不一致会带来权限错乱。我见过一个真实事故:两台机器上同一个运维账号 UID 不同,导致 NFS 共享目录里的文件一会属于这个用户一会属于另一个用户,排查了很久才发现是 UID 不一致。所以,有条件的话尽量规划一个固定的 UID 段,例如开发人员 UID 从 10000 开始,运维账号 UID 从 20000 开始,好记又不跟系统默认冲突。
1.2 登录方式与权限边界规划
创建用户前还要定一件事:这个账号到底怎么登录、能登录到哪一步。有三种典型情况:
- 需要 SSH 登录服务器,进入命令行操作:分配 /bin/bash 或 /bin/zsh 作为登录 Shell。
- 只需要能访问文件服务或者跑应用,不需要进入 Shell:登录 Shell 设为 /sbin/nologin 或 /bin/false。
- 服务进程专用的账号:不仅不能登录,最好连家目录都不要,或者用一个独立目录只放应用数据。
这个决定要提前做,因为默认 Shell 一旦定错,用户登录体验会非常诡异——比如你能通过 SSH 连上但立马被断开,大多数情况就是登录 Shell 设成了 nologin 而你自己不知道。
权限边界也要提前规划好:这个用户需要 sudo 吗?需要加入哪些附加组?比如想让用户能读取日志,可能得加入 adm 组;想让用户能用 docker 命令,得加入 docker 组;想让用户管理 Web 服务,得考虑将他加入 www-data 组。这些组关系在创建用户时顺手加好,比用户登录后再单独改要干净得多。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手创建:adduser 与 useradd 的实战差异
2.1 useradd 参数逐项拆解
Linux 创建用户的核心命令是 useradd(或 adduser,但不同发行版有区别,后面细说)。很多人在这一步就开始踩坑,因为 useradd 的参数实在太多了。我这里把最常用的几个拆开讲。
bash复制sudo useradd -m -d /home/zhangsan -s /bin/bash -G adm,docker -c "Zhang San" -u 10001 zhangsan
逐个解释:
- -m:创建家目录。不加这个参数,系统不会自动建 /home/zhangsan,很多新手漏了这一项,结果用户一登录就提示“No directory, logging in with HOME=/”。
- -d:指定家目录路径。默认是 /home/用户名,除非有特殊需求,一般用默认就行,没必要特意写。
- -s:指定登录 Shell。建议写成 /bin/bash,如果你系统里装了 zsh 也可以写 /usr/bin/zsh。比较稳妥的做法是先执行
which bash或cat /etc/shells查看可用的 Shell 路径,别凭感觉写。 - -G:指定附加组。注意是大写 G,小写 -g 是指定主组。我用 -G 把用户加入 adm 和 docker 组,方便后续管理。多个组用逗号分隔,中间不要有空格。
- -c:用户备注信息。一般写用户真实姓名或岗位,方便后期维护时知道这个账号是谁。
- -u:手动指定 UID。如果你有前面说的 UID 规划,就用这个参数。
创建完用户后,立刻检查一下:
bash复制id zhangsan
ls -ld /home/zhangsan
id 命令能确认用户和组关系是否创建正确,ls 命令能确认家目录是否生成且属主正确。我用这几条命令的次数,比任何运维工具都多。
2.2 adduser 交互式流程
如果你用的是 Ubuntu 或 Debian 系系统,还会遇到 adduser 命令。注意,这里有个经典的发行版差异问题:
- 在 Debian/Ubuntu 上,adduser 是一个 Perl 脚本,它会帮你完成创建用户、建家目录、拷入默认配置、设置密码等一系列操作,交互式引导非常友好。
- 在 CentOS/RHEL 上,adduser 其实是 useradd 的一个软链接,执行效果等同于 useradd,并不会引导你设置密码。
所以网上教程说“adduser 创建用户”,你得先确认自己是什么系统。我自己的习惯是:如果是 Ubuntu,创建单个用户优先用 adduser,因为它更省事;如果是 CentOS 或要写批量脚本,直接用 useradd。
Ubuntu 下 adduser 的典型过程:
bash复制sudo adduser zhangsan
执行后系统会问你设置密码、再输一次密码、然后填一堆可选信息(姓名、房间号、电话等)。这些信息直接按回车跳过也可以,但建议至少填一个 Full Name,方便后期识别。
2.3 批量创建用户的脚本实践
如果你在一台新服务器上要给整个团队开账号,一条条 useradd 太慢了。我一般会写一个简单的批量脚本,用文件驱动:
bash复制#!/bin/bash
# add_users.sh
# 用户信息文件格式:用户名:UID:附加组:备注
USER_LIST="/tmp/user_list.txt"
while IFS=: read -r username uid groups comment; do
if id "$username" &>/dev/null; then
echo "用户 $username 已存在,跳过"
continue
fi
if [ -n "$uid" ]; then
useradd -m -u "$uid" -s /bin/bash -G "$groups" -c "$comment" "$username"
else
useradd -m -s /bin/bash -G "$groups" -c "$comment" "$username"
fi
echo "$username:初始密码123" | chpasswd
chage -d 0 "$username"
echo "用户 $username 创建完成"
done < "$USER_LIST"
/user_list.txt 内容格式:
code复制zhangsan:10001:adm,docker:张三
lisi:10002:docker:李四
这段脚本里有几个点要解释:chpasswd 是从标准输入读取“用户名:密码”并批量更新密码,比在脚本里用 passwd 交互式输入方便得多;chage -d 0 是强制用户第一次登录后修改密码,这样初始密码即使写死在脚本里也不怕,用户登录后自己必须改掉。
3. 环境初始化:让新账号开箱即用
3.1 密码策略与首次登录强制改密
用户创建好只是第一步,真正的“初始化”从密码策略开始。很多公司的安全基线要求新用户首次登录后强制改密,这个功能靠的就是 chage 命令。
强制用户首次登录后改密:
bash复制sudo chage -d 0 zhangsan
-d 0 表示将密码最后一次修改日期设置为 1970-01-01,这样系统会认为密码已经过期,用户下次登录时会立即被要求设置新密码。这个动作我建议在创建用户后立刻执行,不要等用户自己来找你说“密码登不上去”。
设置密码有效期和过期提醒:
bash复制sudo chage -M 90 -m 7 -W 14 zhangsan
-M 90 是密码最长使用 90 天,-m 7 是最少间隔 7 天才能再次修改,-W 14 是在密码过期前 14 天开始提醒用户。这是比较常见的策略,具体数值根据你公司的安全要求来。
用命令查看用户当前的密码策略:
bash复制sudo chage -l zhangsan
输出里能看到最近修改时间、密码过期时间、密码失效时间等字段,排查询问题时会用上。
3.2 Shell 环境与 .bashrc 定制
新用户的家目录哪里来?答案是 /etc/skel 目录。这个目录里的文件会在创建用户时自动复制到新用户的家目录,包括 .bashrc、.profile、.bash_logout 等。所以你要做的不是等用户建好后再去补环境,而是提前把 /etc/skel 里的公共配置维护好。
我的 /etc/skel/.bashrc 里通常会追加这些内容:
bash复制# 自定义 PS1 提示符,显示用户名、主机名、当前目录
export PS1='\[\e[32m\]\u@\h\[\e[0m\]:\[\e[34m\]\w\[\e[0m\]\$ '
# 常用别名
alias ll='ls -alF'
alias la='ls -A'
alias grep='grep --color=auto'
alias df='df -h'
alias free='free -h'
# 历史记录优化:记录时间戳,忽略重复命令
export HISTTIMEFORMAT="%F %T "
export HISTSIZE=10000
export HISTFILESIZE=20000
export HISTCONTROL=ignoredups
# 如果当前用户不是 root,提示符里也可以加个颜色区分的符号
# 你自己可以再加常用的 PATH
这几个配置看起来很基础,但能极大提升日常操作的幸福感。尤其 HISTTIMEFORMAT,审计的时候非常有用——谁在什么时候执行了哪条命令,一目了然。如果不加,/root/.bash_history 或用户 home 下的历史文件里只有一条条光秃秃的命令,查问题要靠猜。
需要注意一个坑:.bashrc 是针对交互式非登录 Shell 生效的,而 .bash_profile(或 .profile)是针对登录 Shell 生效的。SSH 登录服务器时通常是通过 .bash_profile 再间接调用 .bashrc,所以如果两边配置不一致,可能出现在终端里环境正常、但一执行 ssh user@host command 就找不到命令的情况。针对这种非交互式调用,环境初始化最好写在 /etc/environment 或者 /etc/profile.d/ 下的脚本里,确保所有上下文都能读到同一个 PATH。
3.3 sudo 权限分配的最小化实践
新用户如果需要管理员权限,不能直接把 root 密码给他,而是要通过 sudo 做精细化授权。修改 sudo 配置必须用 visudo 命令,它会帮你做语法检查,避免写错导致 sudo 全部失效。这点非常重要,我见过有人直接 vim /etc/sudoers 改坏导致 root 都无法提权的惨案。
简单场景:给 zhangsan 完整的管理员权限。
bash复制sudo visudo
在文件里加一行:
code复制zhangsan ALL=(ALL:ALL) ALL
复杂场景:只允许他执行特定命令。
code复制zhangsan ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
这段配置的意思是 zhangsan 可以免密(如果你加 NOPASSWD)或以密码验证方式执行 nginx 的重启和重载命令,而没有权限执行其他任意命令。这种最小化授权在中大型团队里很重要,尤其是线上服务器,谁都不希望一线开发有权限把整个系统改造一遍。
关于 NOPASSWD 有一个经验:开发环境图省事可以配 NOPASSWD,但生产环境强烈不建议。否则一旦账号密码泄露,攻击者连密码验证都不用就能直接 root 执行命令,审计日志里也会少一道关卡。
3.4 开发机场景:从用户初始化到开发环境联动
如果这台机器要当开发机用,创建用户之后往往还要初始化一套开发环境。很多团队会把 Python、Node.js、Java 装到系统全局目录,然后所有用户共用一套版本。这么做短期挺方便,但版本一升级就全员受影响,某一个项目需要旧版本就只能干瞪眼。
我的建议是:新用户创建并初始化好基础环境后,开发语言环境尽量用用户级版本管理器,不要让每个人去动系统全局。以 Python 为例,建议新用户自己装 pyenv:
bash复制sudo apt install -y build-essential libssl-dev zlib1g-dev libbz2-dev \
libreadline-dev libsqlite3-dev libncursesw5-dev xz-utils tk-dev libxml2-dev \
libxmlsec1-dev libffi-dev liblzma-dev
然后以 zhangsan 身份执行:
bash复制curl https://pyenv.run | bash
再把环境变量写进用户自己的 .bashrc。同理,Node.js 推荐 nvm,Java 可以用 sdkman。这样每个用户都拥有独立的语言版本控制权,互不干扰。从系统运维角度来看,系统里只需要保留基础工具链,开发依赖全部隔离在用户级目录,排查问题也会简单很多。
同样,很多团队会给开发账号预置 SSH 公钥到 authorized_keys 里,省掉用户自己配置的步骤,这个操作放到下一节“安全加固”里统一讲。
4. 权限边界与安全加固
4.1 SSH 密钥登录配置
新用户初始化里最容易被忽略的安全项就是 SSH 登录方式。只设一个密码是危险的,尤其如果你的服务器还暴露在公网上,弱口令爆破几乎是分分钟的事。
正确的做法:给用户配置密钥登录,然后关闭或限制密码登录。
先把公钥放到用户家目录:
bash复制sudo mkdir -p /home/zhangsan/.ssh
sudo sh -c 'echo "ssh-ed25519 AAAA...用户公钥内容" > /home/zhangsan/.ssh/authorized_keys'
sudo chown -R zhangsan:zhangsan /home/zhangsan/.ssh
sudo chmod 700 /home/zhangsan/.ssh
sudo chmod 600 /home/zhangsan/.ssh/authorized_keys
权限这一步很多人会忘。SSH 服务端对 .ssh 目录权限非常敏感,如果权限过宽,比如 .ssh 是 755,或者 authorized_keys 是 644,sshd 根据 StrictModes 会直接拒绝使用密钥登录,日志里报 “Authentication refused: bad ownership or modes”。这时候你以为是密钥写错了,其实是权限没调对。
如果你要批量给多个用户灌公钥,可以写个 shell 循环,但一定要通过 sudo 执行并注意每个用户目录的属主归属。
建议在 /etc/ssh/sshd_config 里做以下调整:
code复制PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
改完以后 sudo systemctl reload sshd 生效。这里有个提醒:在生产环境关密码登录之前,务必确认你自己至少有两把不同的密钥都能登录,或者有带外管理通道(比如云控制台的 VNC),不然一旦配置写错,你可能会被自己锁在门外。
4.2 账户状态检查与审计
用户建好了,密钥也配好了,不代表就一劳永逸。建议定期做一次账户巡检,看看系统里有没有过期账号、异常登录记录、可疑的 UID 0 账号。
几条常用检查命令:
bash复制# 查看所有普通用户及其 UID
awk -F: '$3 >= 1000 {print $1, $3, $6, $7}' /etc/passwd
# 查看哪些用户有登录 Shell
grep -v '/sbin/nologin\|/bin/false' /etc/passwd
# 查看所有用户的最近登录记录
lastlog
# 查看当前登录用户及来源
last
# 检查是否存在 UID 为 0 的非 root 用户
awk -F: '$3 == 0 {print $1}' /etc/passwd
最后一条尤其重要。正常情况下系统里只应该有一个 UID 0 用户,就是 root。如果你发现某个陌生的用户名 UID 是 0,基本可以确定这台机器已经被拿下了,这是入侵者最常留后门的方式之一。
另外,建议把 /etc/passwd、/etc/shadow、/etc/group 的修改记录纳入监控。用户管理层面的异常,往往比应用崩溃信号更早暴露风险。
4.3 用户生命周期管理
有创建就必然有删除。用户生命周期管理也是初始化工作的一部分,尤其是权限回收要及时。
锁定用户而不是直接删除:
bash复制sudo usermod -L zhangsan
锁定之后用户无法通过密码登录,但是 SSH 公钥登录是否还能用取决于 sshd 配置。彻底禁止登录可以把 Shell 改成 nologin:
bash复制sudo usermod -s /sbin/nologin zhangsan
确定要删掉账号时:
bash复制sudo userdel -r zhangsan
-r 参数会一并删除用户的家目录和邮件池。但这个参数要慎用,如果用户家目录里有重要项目代码或未备份的数据,删掉就找不回来了。我一般的操作习惯是:先锁定账号,保留家目录一到三个月,确认确实没有数据需求之后再连目录一起清理。
还有一个细节:userdel 删除用户不会自动删除该用户拥有的、但位于其他目录下的文件。你可以在删除之前通过 find / -user zhangsan 扫一遍,把这些文件先归集或者备份,防止磁盘上遗留一堆孤儿文件。
5. 常见问题排查与面试考点
5.1 高频故障速查表
这部分我整理了一张速查表,都是我在实际运维中反复遇到过的问题:
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 用户创建成功但无法登录 | Shell 被设为 /sbin/nologin 或 /bin/false | `cat /etc/passwd |
| 登录后显示 “No directory, logging in with HOME=/” | 缺少家目录或家目录权限不对 | ls -ld /home/用户名 确认目录存在且属主正确 |
| 无法用 SSH 密钥登录 | authorized_keys 权限不对或 .ssh 目录属主不对 | 检查 .ssh 和 authorized_keys 权限,0 时对照 StrictModes |
| 明明加了 sudo 组却无法执行 sudo | 用户不在 sudo 组,或 sudoers 配置写错 | groups 用户名 确认组;sudo visudo -c 检查语法 |
| 切换用户后命令找不到 | PATH 环境变量未初始化 | 检查 .bashrc / .bash_profile 是否有错误输出,逐行执行排查 |
| chage -d 0 强制改密后登录闪退 | 有的系统会自动断开,要求用 passwd 修改后才能继续 | 让用户 SSH 登录后立即执行 passwd 修改密码 |
| 用户能登录但显示乱码或中文显示异常 | LANG / LC_ALL 环境变量没配置 | 在 .bashrc 里 export LANG=en_US.UTF-8 或 zh_CN.UTF-8 |
| 其他用户能看到该用户家目录内容 | 家目录权限被改成了 755 或更松 | chmod 700 /home/用户名 收紧权限 |
5.2 容易忽略的细节坑
有几个坑几乎每个新手都会踩,我单独拿出来说。
第一个坑是交互式 Shell 和非交互式 Shell 的配置加载误区。SSH 登录后是登录 Shell,非登录 Shell 则常见于脚本内执行命令或 tmux/screen 的新窗口。很多人的自定义环境变量写在 .bashrc 里,但脚本通过 ssh host command 这种方式远程执行时走的不是登录 Shell,有些发行版连 .bashrc 都不会读取(比如在 /etc/profile 和 .bash_profile 里必须手动 source),导致远程执行找不到命令。解决办法是把公共 PATH 写进 /etc/environment 或 /etc/profile.d/ 下独立脚本,保证不管什么上下文都能读到。
第二个坑是 UID 冲突。手动指定 UID 时如果跟已有用户重复,不会直接报错,但登录后你会发现 id 显示的用户名跟你预期不一致,文件所有者也可能会出现两个用户名指向同一个 UID 的混乱情况。所以批量创建前先执行 awk -F: '$3 >= 1000 {print $3}' /etc/passwd | sort -n 看一下已分配的 UID 段。
第三个坑是家目录权限过大。有些安装向导会把 /home 下目录权限改成 777,导致任何用户都能读写你的文件,这在安全审计里是严重违规项。普通用户家目录应该保持 700 或 750,只有用户自己和 root 能访问。
第四个坑是 sudo 配置语法错误导致全线崩溃。前面提过必须用 visudo 而不是直接 vim,这里再强调一次。一旦 /etc/sudoers 语法错误,所有用户的 sudo 都会失效,你又不能用 sudo 去改回文件——幸好 visudo 在保存前会做语法检查,否则真的会陷入鸡生蛋蛋生鸡的死循环。
5.3 面试中容易翻车的几个细节
由于“Linux 面试题”这类搜索量很大,这里顺手把跟用户管理相关的几个高频面试点串一遍。
useradd 和 adduser 的区别:在 Debian/Ubuntu 上 adduser 是 Perl 脚本,交互式引导创建;在 CentOS/RHEL 上 adduser 是 useradd 的符号链接。本质上,useradd 是底层命令,adduser 是上层封装。
/etc/skel 目录的作用:新用户家目录里的初始配置文件模板,创建用户时系统会把 /etc/skel 下的所有文件(含隐藏文件)复制过去。修改这个目录会影响后续所有新用户。
/etc/passwd 每一行各字段含义:用户名、密码占位符 x、UID、GID、备注、家目录、登录 Shell。密码真实内容在 /etc/shadow 里,shadow 每个字段包含加密密码、最后修改时间、最短修改间隔、最长有效期、过期前几天提醒、失效日期等。
UID 0 的特殊含义:只有 root 的 UID 是 0,如果发现其他用户是 UID 0,等同于这个用户拥有超级管理员权限。
如何强制用户首次登录改密:chage -d 0 用户名,或者 passwd -e 用户名,两条命令效果类似。
sudo -i 和 sudo -s 与 su - 的区别:sudo -i 是切换到 root 并加载 root 的登录环境,sudo -s 是切换 root 但保留当前用户的环境变量,su - 则是完整切到 root 的登录 Shell。面试官经常问区别,其实核心就是环境变量加载路径不同。
写在最后:我的一点个人习惯
用户创建和初始化这件事做了这么多年,我自己慢慢形成了一套固定打法:新账号进来先建普通用户、配密钥、走最小权限,绝不一上来就发个 root;然后根据岗位把附加组和 sudo 权限一次性配好,省得后续反复申请;接着检查一遍 /etc/skel 的公共配置,确保新用户第一次登录就有规范的环境;最后把账号信息记录到维护清单里,注明负责人、用途、预计回收时间。
这套流程看起来繁琐,但每次排查问题时都帮我省下了大把时间。最后再分享一个小技巧:每次创建完新用户后,我都会顺手执行一条 awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd,快速过一遍当前系统里的所有普通用户及 Shell,确认没有异常账号混进来。这个动作十秒钟不到,但能让整个系统的用户管理始终处于一个清晰可控的状态。
