服务器新建用户配置相同，核心是把用户属性、默认文件和初始化环境这三层内容固化成一个标准模板，再通过一条命令批量下发，彻底告别每台服务器手动逐项设置的低效和配置漂移问题。
新换几台服务器，用户配置不一样有多折磨人
想象一个场景,公司新采购了一批服务器，或者你刚从老同事手里接手一套线上环境，你登录第一台机器，按老习惯敲了useradd，接下来设置密码、配置sudo权限、把密钥放上去、设置好umask和环境变量，测一下，没问题，然后你登录第二台机器，重复同一套动作，磕磕绊绊，输错一个字母没注意，再到第三台机器，你突然忘了上次给那个新同事的UID是多少。
这就是很多运维日常的真实状态,给一台服务器新建用户，五分钟能搞定，但给一批服务器新建用户，每个用户都要重复同样的操作，二十分钟也许不够，而且结果往往不一样，有的机器sudo规则带NOPASSWD，有的机器身份认证用的密钥没拷全，有的机器用户登录之后环境变量缺了JAVA_HOME。
这类问题在混合机房环境尤其明显,物理机、虚拟机、云主机混在一起，操作系统版本有7有8，发行版有CentOS有Ubuntu，用同一条交互式命令操作，很容易出现偏差，排查起来也很费神。
配置相同具体要做哪些事
把“配置相同”这个概念拆开，实际上包含四个层面，每一项都落在具体的文件或命令上。
用户基础属性必须一字不差
包括用户名、UID、GID、用户组、用户注释、家目录路径、登录Shell。UID和GID一定不要顺手乱指定，尤其在涉及NFS共享存储的环境里，两台机器的UID对不上，创建出来的文件属主显示就会乱码，看着像数字，其实两边根本不认。
默认初始化文件要统一
用户创建后,/etc/skel目录下的文件会按模板复制到家目录里，这个目录里通常放着.bash_profile、.bashrc、.vimrc等文件，如果想给每个新用户一个统一的环境，直接把配置写进/etc/skel即可。
权限和提权规则要一致
sudoers文件里配置了用户能执行什么命令、要不要密码，属于系统安全和效率的高敏感区，一致性要求极高。
认证方式和密钥分发不是可选项
如果公司统一用SSH密钥登录,那新用户的公钥必须追加到目标机器的authorized_keys文件里，同时得保证.ssh目录权限是700，文件权限是600，权限稍有偏差，密钥直接失效，就算做完了排查也绕。
那个最常用也最容易忽略的姿势：改好skel文件再批量建用户
行业内共识认为,追求配置相同，最好的办法不是事后纠偏，而是从源头统一模板
。/etc/skel目录就是Linux系统用来铺新用户底子的地方。
修改/etc/skel里的.bashrc，比如加上一个标准别名和默认的umask值，之后新建的所有用户都会自动带上这段逻辑，不需要再单独去每台机器配，操作方法是：
- 先在一台基准服务器上编辑好
/etc/skel/.bashrc以及其它想统一的文件。 - 用
scp或者配置管理工具把整个/etc/skel目录同步到其他服务器的相同目录下。 - 后续创建用户时,系统会自然使用这份统一模板。
不过这个方案有局限,它只管理新用户，有些老用户没那么完整，需要一个单独机制去校正。
三条主流的批量化实施路径
方案各有千秋,选型取决于你有多少台机器，是否已有配置管理工具链。
方案A：直接用一条命令带全部参数创建
适合几台机器的小规模场景,手动或半自动执行，把用户名和UID规划写好，然后依次执行。
第一步,在每台机器上检查现有用户ID占用情况，避免冲突。
第二步,执行useradd命令，把参数写全，不要用交互式让你慢慢选。
useradd -u 1501 -g dev -G wheel -d /home/zhangsan -s /bin/bash -m zhangsan第三步,用echo "密码" | passwd --stdin zhangsan设置初始密码。
第四步,追加sudo规则，操作/etc/sudoers.d/zhangsan文件，写入如zhangsan ALL=(ALL) NOPASSWD: ALL，改完之后用visudo -c校验语法。
第五步,把密钥文件放到指定位置，同时设置正确权限。
这条链路适合要管理的机器数量很少的场景,问题在于，每次新增用户都要重复整套动作，而且因为一半是手敲命令，容易输漏。
方案B：借助Ansible等工具做成可重复执行的剧本
稍微上点规模或者超过5台以上机器时,建议直接用Ansible批量执行，把用户创建的所有步骤集成进一个Playbook，包含用户建立、配置sudo命令、同步密钥文件，每次新建用户只需要在vars里改一下用户名和新用户的UID，就可以执行。
按照业内实践,配置核心是这几个任务模块：
user模块：统一管理用户创建，可以参数化用户名、UID、组、家目录。copy或file模块：把/etc/skel里的模板分发过去，顺便修正权限。lineinfile模块：往sudoers文件或者独立的sudo配置里追加规则。authorized_key模块：管理SSH公钥下发。
批量跑一次,所有机器的状态就保持一致，手动敲错命令的概率大幅降低。
方案C：构建统一身份认证中心，从根上不做重复建设
如果公司规模大,或者服务器数量相当多，建议使用LDAP或Windows AD域控，把用户认证从每台机器抽离出来，服务器无需再单独创建用户，而是通过sssd、winbind组件对接认证中心，直接用统一用户登录。
这种方案的配置相同问题被架构层面完全消除,一台服务器的新用户配置只需在认证中心做一次，其余机器自动生效，缺点是搭建门槛较高，不适合只有三台机器的轻量环境。
考虑到各自适用场景,见下表：
| 方案 | 适用场景 | 投入成本 | 一致性效果 | 新增用户操作 |
|---|---|---|---|---|
| 手动useradd | 1-3台 | 极低 | 依赖细心程度 | 逐台执行 |
| Ansible剧本 | 数台到数十台 | 中低 | 较高且可重复 | 改变量后执行 |
| LDAP/AD统一认证 | 数十台以上 | 较高 | 最高 | 只需在目录中新建一次 |
做一个可重复复用的配置模板脚本
如果你不想引入重量级工具,又不想完全手动，可以在服务端写一个带参数的Shell脚本，专门应对“多台服务器新建用户配置相同”这种重复劳动，脚本的逻辑维持清晰：
- 接收
username、uid、group作为外传参数。 - 自动检查用户是否已存在,存在就不重复执行并给出提示。
- 完成建用户、设密码、追加sudo规则、部署密钥四步。
- 将执行日志输出到独立文件,便于回顾。
把脚本放到一台跳板机上,每次添加用户时执行一次，通过建立hosts列表循环ssh执行，整体速度也够，在混合云环境里，还可以配合各云厂商的“自定义数据”功能，在实例首次启动时自动执行脚本完成用户创建，效率较高且不会出现遗漏。
新老用户配置不一致的排障思路
碰到改完仍有不一致的情况,优先查看下面三项，多数问题都集中在这几个点上：
- 用户ID是否冲突，使用
id 用户名命令核对，再和另外一台服务器比对，确认完全一致。 - sudo规则语法问题，这属于重点排查项，如果sudoers文件某个环节加错了，影响用户执行任务，使用
visudo -c检查，系统会直接提示出错位置。 - 家目录权限问题，如果用户认证通过但登录后环境怪异，比如命令提示符不对、密钥不生效，多半是
.ssh目录权限或/etc/skel覆盖不彻底导致。
还有一种常见情况,基于自定义镜像批量购买的云服务器，预先打包的操作系统里，账号情况各不相同，要么统一用脚本重置，要么干脆使用云厂商的“运行命令”功能，例如在控制台对多台实例统一执行一段重置和创建用户的操作，避免反复登录每台机器去人工排查账号具体情况。
给MySQL、Nginx这类专属服务账号做的同步配置
不只是运维同事的人工登录账号会遇到配置一致性问题,数据库实例、Nginx worker进程等程序专属运行账号同样适用上面这套思路，程序账号通常要求更严格，建议做到：
- 固定UID和GID,禁止自动分配，确保日志和临时文件的属主在各服务器完全一致。
- 指定家目录为或
/var/empty，规避程序账号被直接登录的安全风险。 - 禁用Shell登录,使用
/sbin/nologin，减少无谓攻击面。 - 把程序启动需要的环境变量统一写进服务的systemd unit文件里，而不是放靠bashrc这类交互式配置，也不建议依赖每台机器手改。
把配置固化到自动化流程里
这一步属于长远会计分录,真正意义上处理好服务器新建用户配置相同的问题，需要把生成账户的流程纳入日常自动化体系的某个环节。
行业专家指出,大多数配置不一致问题都是因为有人绕过了标准流程，手动在单机上做了差异操作，所以最终解决的路径是：
把用户创建的动作脚本化、模板化、版本化，放进Git仓库里管理。 建立类似ops-users的仓库，里面用目录结构放好各用户目录下的配置文件、密钥、角色定义，使用Ansible或脚本定期检核，发现漂移自动纠正或告警，这样任何人添加新用户，不再是靠记忆操作，而是依据模板修改代码实现标准化流程，自然会保证每一台机器上的用户配置完全一致。
常见问题解答
服务器新建用户配置相同怎么做最省事？
最省事的是把/etc/skel目录彻底修改好，并结合一套批处理脚本或自动化工具执行，操作路径是：先在基准机上改好模板，再让脚本对所有机器统一执行useradd、chpasswd、创建sudo规则和部署SSH密钥这四步操作，实现全部同步统一。
批量新建用户时，UID和GID需要刻意指定的场景是什么？
当服务器使用了共享存储、NFS挂载或对接统一日志收集系统时，相当一部分问题都源于UID和GID的不统一，遇到这一情况，建议显式指定固定的UID和GID，不要依赖每台机器自动分配，避免出现文件属主错乱和权限访问异常这两类问题。
服务器新建用户配置相同命令本身和修改模板文件，哪种方式更推荐？
如果只操作一到两台服务器,使用命令参数完整列出所有设置就可以，比如useradd、usermod配合使用；如果操作对象达到一定数量级别，修改/etc/skel和封装备份再批量分发的做法更推荐，前者解决的是单机效率问题，后者解决的是多机一致性问题，多数情况下结合使用效果更好。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/585923.html
