企业官网建设流程全解析

1. 为什么在VPS上不用图形界面也要死磕passwd和adduser？

你买了一台甲骨文VPS、腾讯云轻量应用服务器，或者自己搭的Rocky Linux虚拟机，SSH连上去第一眼看到的是黑底白字的命令行。没有“设置”图标，没有“用户管理”菜单，更没有“重置密码”的找回链接——所有账户安全的命脉，全系于两个看似简单的命令：passwd和adduser。

这不是Linux老手的炫技，而是VPS运维的生存底线。我去年帮一个做跨境电商的朋友排查订单系统异常，查到最后发现不是代码bug，而是他用useradd随手建的worker用户，没设密码，又被脚本自动调用执行了高权限任务，结果被扫描器撞库成功，整个数据库配置文件被拖走。而如果当时他用的是adduser，系统会强制交互式设置密码强度、主目录、shell类型；如果他后续改密码时用的是passwd而非直接编辑/etc/shadow，也不会因格式错误导致整个用户登录体系瘫痪。

这两个命令之所以成为VPS管理的“心脏级工具”，根本原因在于它们直连Linux身份认证的底层三件套：/etc/passwd（用户元数据）、/etc/shadow（加密密码）、/etc/group（组权限映射）。它们不依赖任何桌面环境、不经过Web控制面板的中间层、不绕过PAM（Pluggable Authentication Modules）认证框架——这意味着每一次执行，都是对系统真实状态的原子级操作。你敲下回车的那一刻，系统就按最原始、最不可篡改的方式完成了身份凭证的写入或更新。

所以别被“基础命令”四个字骗了。passwd不是改个密码就完事，它背后是SHA-512盐值加密算法的实时运算；adduser也不是建个账号那么简单，它要同步创建家目录、复制骨架文件、设置umask权限掩码、初始化bash配置、甚至自动挂载加密卷（如果你配了pam_mount）。这就像汽车的离合器——平时不显山露水，但一旦打滑，整辆车就失去动力传递能力。

尤其在国产Linux发行版（如统信UOS服务器版、麒麟V10）逐步进入政企VPS场景的今天，这些命令的语义和参数行为反而比某些GUI工具更稳定。因为内核和glibc的兼容性保障远高于第三方图形化管理器。你今天在甲骨文VPS上用adduser -m -s /bin/bash -c "API Worker" apiuser建的用户，明天迁移到华为云ECS的openEuler系统，命令依然原样可用——这种跨平台确定性，正是VPS运维最稀缺的资产。

提示：很多新手误以为useradd和adduser是同一个命令的软链接。实则不然。useradd是POSIX标准的底层二进制，功能精简；adduser是Perl脚本封装，提供交互式向导、默认安全策略和错误检查。在生产VPS上，除非你明确需要useradd的静默批处理能力，否则无脑选adduser——它少犯错的概率高出3倍以上。

2.adduser的隐藏开关：那些文档里不写但线上必配的参数

adduser表面看就是sudo adduser username敲完回车，系统问你密码、全名、房间号……但真正在VPS上建生产用户，必须把它的“手术刀模式”打开。我整理了过去三年在27台不同配置VPS（从512MB内存的甲骨文免费实例到32核CPU的腾讯云CVM）上踩过的坑，总结出6个必须显式声明的参数，缺一不可：

2.1-m与-M：家目录不是可选项，而是隔离墙

adduser默认创建家目录（-m），但很多人不知道-M（大写M）才是危险开关。某次给客户部署Kubernetes集群，运维同事图省事用useradd -M kubeadmin建了用户，结果Ansible脚本执行cp ~/.ssh/authorized_keys时报错——因为~指向/root，而kubeadmin根本没有家目录。-M强制禁用家目录，看似节省磁盘，实则让所有基于$HOME路径的自动化脚本集体失效。

正确姿势是：永远显式加-m。哪怕你计划后续用NFS挂载统一家目录，也要先让adduser创建空目录结构。因为/etc/skel里的.bashrc、.profile等骨架文件，只有-m才会复制。这些文件决定了用户登录后的PATH环境变量、历史命令长度、颜色提示符——少了它们，ls --color=auto会变黑白，python3可能找不到模块。

2.2-s /bin/bash：Shell选择决定权限天花板

VPS上最常被忽略的陷阱：新建用户默认Shell是/bin/sh（dash）。这看起来很安全——sh不支持数组、进程替换、[[ ]]条件判断，能防住90%的恶意脚本。但当你用su - apiuser切换过去，发现source ~/.bashrc报错，alias ll='ls -la'不生效，甚至docker-compose up直接退出——因为docker-compose的启动脚本里用了$(...)语法，而/bin/sh根本不认。

解决方案：强制指定-s /bin/bash。但注意！有些精简版VPS镜像（如Alpine Linux的linuxkit）压根没装bash，此时要先apk add bash再执行。更稳妥的做法是检查目标系统：getent shells列出所有合法Shell，选第一个非/bin/sh的。我在Rocky Linux 9上发现/usr/bin/bash才是真实路径，硬写/bin/bash会导致用户无法登录。

2.3-c "描述"：别小看这个字段，它是审计追踪的生命线

-c参数填的不是“张三”这种人名，而是角色+用途+时间戳的组合。比如：-c "jenkins-ci-pipeline-20240520"。为什么重要？因为/etc/passwd第五字段（GECOS）会永久记录这个字符串。当某天安全审计发现/var/log/secure里有异常sudo su -记录，你grepjenkins-ci-pipeline就能瞬间定位到是CI/CD流水线触发的，而非人为操作。如果只写"jenkins"，遇到多个Jenkins实例时根本分不清是测试环境还是生产环境的账号。

实测技巧：用date +%Y%m%d动态生成时间戳。写成-c "monitoring-alert-handler-$(date +%Y%m%d)"，既保证唯一性，又避免手动输错日期。

2.4-u 1001与-g 1001：UID/GID不是数字游戏，而是文件权限锚点

新手常犯的错：adduser -u 500 deploy，以为500是“好记的数字”。但Linux内核规定UID<1000为系统保留（root是0，daemon是1），普通用户必须≥1000。你硬设500，adduser虽不报错，但ls -l看文件时会显示nobody而非用户名——因为getpwuid(500)查不到对应条目。

更致命的是-g（主组ID）。如果-g 1001而/etc/group里没有gid 1001的组，adduser会自动创建同名组，但该组不会加入/etc/gshadow，导致后续用gpasswd管理组密码时崩溃。正确做法是：先groupadd -g 1001 deploygroup，再adduser -u 1001 -g deploygroup deploy。这样UID、GID、组名三者严格对齐，id deploy输出才干净利落。

2.5-e 2025-12-31：账号有效期不是摆设，而是运维防火墙

-e参数设置账号过期时间（YYYY-MM-DD格式）。这招在临时协作场景中救命：给外包开发开VPS账号时，adduser -e $(date -d "+30 days" +%Y-%m-%d) devops-external。30天后账号自动锁定，su - devops-external会提示Your account has expired; please contact your system administrator。比事后手动usermod -L可靠十倍——因为没人会记得30天后去锁账号。

注意：过期≠删除。-e只禁用登录，家目录和文件全在。如需彻底清理，得配合-f 7（密码过期后7天自动删除账号）。

2.6-k /etc/skel-custom：骨架目录才是权限策略的真正起点

/etc/skel是默认骨架目录，但VPS生产环境必须自定义。比如你要禁止用户修改/etc/resolv.conf，就在/etc/skel-custom/.bashrc里加chattr +i /etc/resolv.conf；要强制启用双因素认证，在/etc/skel-custom/.profile里写if [ -f /usr/bin/google-authenticator ]; then exec google-authenticator -t -d -f; fi。

创建自定义骨架：

sudo cp -r /etc/skel /etc/skel-custom sudo chmod 700 /etc/skel-custom sudo chown root:root /etc/skel-custom

然后adduser -k /etc/skel-custom appuser。这样每个新用户登录，第一件事就是执行你预设的安全加固脚本。

注意：-k路径必须存在且root可读，否则adduser静默失败，用户家目录里啥都没有。我见过最惨的案例：运维把/etc/skel-custom权限设成755，结果新用户家目录的.ssh被其他用户遍历，私钥泄露。

3.passwd的七层炼狱：从改密码到锁账户的完整控制链

passwd命令表面只有“改密码”一个功能，但它实际串联了Linux认证体系的七层关卡。理解每一层，才能避免改完密码后用户登不上、登上了却没权限、或者登上了却触发安全警报的诡异问题。

3.1 第一层：密码哈希算法的选择——SHA-512不是默认，而是必须

现代Linux发行版（RHEL 8+/Rocky 9+/Ubuntu 22.04+）默认用SHA-512加密密码，但旧系统或定制镜像可能还在用MD5（已破解）或SHA-256。验证方法：sudo grep "^root:" /etc/shadow，看第二字段开头是$6$（SHA-512）、$5$（SHA-256）还是$1$（MD5）。

为什么必须是SHA-512？因为它的盐值长度达8-16字符，迭代次数默认5000次，暴力破解成本比MD5高10^12倍。passwd本身不指定算法，它依赖/etc/login.defs里的ENCRYPT_METHOD参数。检查并强制设置：

sudo sed -i 's/^ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/' /etc/login.defs sudo sed -i 's/^SHA_CRYPT_MIN_ROUNDS.*/SHA_CRYPT_MIN_ROUNDS 500000/' /etc/login.defs

SHA_CRYPT_MIN_ROUNDS设为50万轮，比默认5000轮慢100倍，但能有效抵御GPU爆破——VPS CPU资源换来的安全冗余，绝对值得。

3.2 第二层：密码复杂度引擎——PAM模块的硬核约束

passwd改密码时，真正校验强度的是PAM（Pluggable Authentication Modules）。/etc/pam.d/common-password（Debian系）或/etc/pam.d/system-auth（RHEL系）里藏着规则。默认的pam_pwquality.so要求：至少1个大写、1个小写、1个数字、1个符号，最小长度12位。

但VPS场景要微调：

• 禁用difok=3（新密码与旧密码至少3字符不同）——因为自动化脚本轮换密码时，旧密码可能已失效；
• 启用retry=3（允许3次输错）——避免用户手抖输错被锁；
• 关键参数minlen=14（最小14位）+maxrepeat=2（禁止连续3相同字符）——防住键盘横向滑动密码如11111111。

修改后立即生效，无需重启。测试：echo -e "weak\nweak" | sudo passwd testuser应报错BAD PASSWORD: The password is shorter than 14 characters。

3.3 第三层：密码生命周期管理——chage才是passwd的幕后推手

passwd本身不管理密码有效期，它调用chage（change age）工具。chage -l username能查看完整策略：

Last password change : May 15, 2024 Password expires : Aug 13, 2024 Password inactive : Aug 20, 2024 Account expires : never Minimum number of days between password change : 7 Maximum number of days between password change : 90 Number of days of warning before password expires : 14

生产VPS必须强制：

• chage -M 90 username（90天必须换密）
• chage -m 7 username（换密后7天内不准再换）
• chage -W 14 username（到期前14天开始警告）

为什么-m 7关键？防止用户用脚本每小时换一次密码，绕过-M 90限制。-W 14则确保ssh登录时终端弹出Warning: your password will expire in 14 days，比邮件提醒更及时。

3.4 第四层：账户锁定机制——passwd -l不是删账号，而是焊死门锁

sudo passwd -l username会在/etc/shadow第二字段密码前加!，变成!$6$abc...。这招比usermod -L更彻底——-L只是在密码前加!!，而-l加!后，即使有人暴力破解出明文，也无法登录，因为!表示“密码无效”。

但注意：-l不阻止su - username（如果知道root密码），也不影响sudo授权。要彻底封杀，得配合：

sudo usermod -s /sbin/nologin username # 禁用shell sudo usermod -L username # 锁密码

/sbin/nologin比/bin/false更友好——它会返回This account is currently not available，而不是沉默退出，方便排查。

3.5 第五层：密码历史追溯——/etc/security/opasswd是你的取证现场

Linux默认记录最后5次密码哈希（/etc/security/opasswd），防止用户循环使用旧密码。但VPS上建议调高：

sudo sed -i 's/pam_pwhistory.so.*/pam_pwhistory.so remember=24/' /etc/pam.d/common-password

remember=24存24次，覆盖2年（按90天换一次算）。这样当安全事件发生，你能快速确认：攻击者是否复用了2年前的密码？如果是，说明初始密码就不合规。

3.6 第六层：SSH密钥与密码的共存博弈——/etc/ssh/sshd_config的终极裁决

passwd改的只是系统密码，但VPS用户通常用SSH密钥登录。这时PasswordAuthentication yes/no才是最终判决者。常见误区：passwd改了密码，但/etc/ssh/sshd_config里PasswordAuthentication no，用户依然登不上——因为SSH压根不读/etc/shadow。

正确流程：

1. sudo passwd username设置强密码（作为应急通道）；
2. sudo nano /etc/ssh/sshd_config确保PasswordAuthentication yes；
3. sudo systemctl restart sshd重载配置；
4. 用ssh -o PubkeyAuthentication=no username@vps-ip测试纯密码登录。

提示：腾讯云VPS默认禁用密码登录，只允许密钥。必须先用密钥登录，再改sshd_config，否则改完就把自己锁在外面。

3.7 第七层：审计日志溯源——/var/log/secure里的每一行都是证据

每次passwd执行，都会在/var/log/secure（RHEL系）或/var/log/auth.log（Debian系）留下记录：

May 20 10:23:45 vps passwd[12345]: password changed for username May 20 10:23:46 vps passwd[12345]: pam_unix(passwd:chauthtok): password changed for username

生产VPS必须配置日志轮转和远程备份。用logrotate每天压缩/var/log/secure，并rsync到独立审计服务器。当某天发现username账号被用于挖矿，你grep日志就能看到：May 18 02:15:22 vps passwd[999]: password changed for username——说明密码是在18号凌晨被篡改的，立刻排查18号凌晨的登录记录。

4./etc/passwd文件解剖：一行代码暴露的12个系统真相

/etc/passwd是Linux的“用户身份证簿”，每行7个冒号分隔的字段，看似简单，实则暗藏12个影响VPS稳定性的关键信息。我拿一台刚装好的Rocky Linux 9 VPS的root行来逐字段拆解：

root:x:0:0:root:/root:/bin/bash:/dev/null:/dev/null

4.1 字段1：用户名（root）——大小写敏感的权限入口

root必须全小写。曾有个客户把用户名设成Root，结果sudo -u Root command报错unknown user Root，因为getpwnam()函数严格区分大小写。更隐蔽的坑：/etc/passwd里用户名不能含.（点），否则systemd-logind会拒绝创建session，导致GUI登录失败（虽然VPS不用GUI，但某些容器化服务依赖此机制）。

4.2 字段2：密码占位符（x）——真正的密码在别处

x表示密码哈希存于/etc/shadow。如果这里写*或!，表示账户被usermod -L锁定；如果为空（::），表示无密码——这是巨大安全漏洞！ssh username@vps-ip直接登录。检查命令：awk -F: '$2 == "" {print $1}' /etc/passwd，输出为空才安全。

4.3 字段3：UID（0）——数字0是上帝权限，但别乱用

UID 0拥有内核级特权：可绕过所有文件权限检查、加载内核模块、绑定1024以下端口。root的UID必须是0，但绝不允许创建第二个UID 0用户。曾见某运维为图方便useradd -u 0 admin，结果admin用户删除/etc/shadow后，整个系统无法登录——因为root的密码记录也被删了。

4.4 字段4：GID（0）——组ID不是附属品，而是权限继承链

GID 0是root组。普通用户GID应与其主组一致。比如deploy用户GID应为deploy组的GID（如1001），而非0。否则ls -l显示deploy deploy，但groups deploy却显示deploy root，导致sudo规则混乱。

4.5 字段5：GECOS（root）——第五字段是审计黄金线索

GECOS字段（root）包含用户全名、办公室、电话等，但VPS上应填角色标识。如jenkins-build-server。这样ps aux | grep jenkins时，一眼看出进程归属。getent passwd jenkins输出的第五字段就是这个字符串，监控脚本可据此分类告警。

4.6 字段6：家目录（/root）——路径末尾不能有斜杠

/root/（带斜杠）是致命错误！cd ~会变成/root//，某些老旧脚本（如/etc/cron.daily/standard）会因此解析失败。adduser自动处理，但手动编辑/etc/passwd时务必检查。

4.7 字段7：登录Shell（/bin/bash）——Shell路径必须真实存在

/bin/bash必须ls -l /bin/bash存在且可执行。Rocky Linux 9中/bin/bash是/usr/bin/bash的软链接，但某些容器镜像里/bin/bash不存在，只有/bin/sh。此时adduser -s /bin/sh username是唯一选择，但要接受功能阉割。

4.8 字段8：登录前脚本（/dev/null）——第八字段是PAM的钩子

POSIX标准只要求7字段，但Linux扩展了第8、9字段。第8字段（/dev/null）是/etc/shadow的过期时间，但/etc/passwd里填/dev/null是占位符。真正过期时间在/etc/shadow第三字段。VPS上此处必须为/dev/null或空，否则login程序会尝试执行该路径脚本，导致登录延迟。

4.9 字段9：账户过期时间（/dev/null）——第九字段决定账号生死

第9字段（/dev/null）是账户过期时间（YYYY-MM-DD格式）。填9999-12-31表示永不过期，填2024-12-31则当天23:59:59后账号锁定。chage -E 2024-12-31 username就是改这个字段。注意：它和密码过期（/etc/shadow第三字段）是两套独立机制。

4.10 安全红线：/etc/passwd的权限必须是644

ls -l /etc/passwd必须显示-rw-r--r--。如果误设成664（组可写），任何属于root组的用户都能echo "hacker:x:0:0::/root:/bin/bash:/dev/null:/dev/null" >> /etc/passwd，瞬间获得root权限。修复命令：sudo chmod 644 /etc/passwd。

4.11 性能陷阱：/etc/passwd过大导致SSH登录延迟

当/etc/passwd超过10MB（约10万用户），getpwnam()查询会变慢。VPS虽不会到这规模，但若用adduser批量建1000个用户，ssh登录时会卡顿1-2秒。优化方案：用nscd（Name Service Caching Daemon）缓存passwd查询。sudo systemctl enable nscd && sudo systemctl start nscd，登录速度提升90%。

4.12 灾难恢复：/etc/passwd损坏后的3分钟自救法

/etc/passwd损坏（如误删一行），su、ssh全挂。别慌，用Live CD或救援模式挂载根分区，执行：

# 假设根分区挂载在 /mnt cd /mnt/etc # 从备份恢复（如果有） cp passwd.bak passwd # 或手动重建root行（最简） echo "root:x:0:0:root:/root:/bin/bash:/dev/null:/dev/null" > passwd # 修复权限 chmod 644 passwd

关键：root行必须存在且UID=0，否则系统无法启动。

注意：/etc/passwd损坏时，sudo也失效（因为sudo要查/etc/passwd确认用户是否存在）。所以VPS管理员必须在/etc下保留passwd.bak备份，每周cp /etc/passwd /etc/passwd.bak。

5. 实战排障：当adduser和passwd突然失灵的7种血泪现场

在VPS上，adduser和passwd报错往往不是命令本身的问题，而是底层系统状态异常。以下是我在生产环境中高频遇到的7类故障，附带逐行排查链路和根治方案。

5.1 故障现象：adduser: Please enter a username matching the regular expression configured via the NAME_REGEX configuration variable.

表象：输入sudo adduser testuser，刚敲完回车就报错，不让你输密码。
根因定位：

• NAME_REGEX定义在/etc/adduser.conf，默认是^[a-z][-a-z0-9_]*\$（小写字母开头，只能含小写、数字、下划线）；
• 你输入的用户名含大写字母（如TestUser）或短横线（test-user）；
• 更隐蔽的是：/etc/adduser.conf被apt upgrade重置，NAME_REGEX被覆盖为更严格的正则。

排查链路：

# 查看当前NAME_REGEX grep "^NAME_REGEX" /etc/adduser.conf # 测试正则是否匹配 echo "testuser" | perl -ne 'print if /^[a-z][-a-z0-9_]*$/' # 如果不输出，说明正则太严

根治方案：

• 用合规用户名：sudo adduser testuser123；
• 或放宽正则（不推荐）：sudo sed -i 's/^NAME_REGEX.*/NAME_REGEX="^[a-zA-Z0-9._-]*$"/' /etc/adduser.conf；
• 永久解决：在/etc/adduser.conf末尾加# Customized for VPS: allow dots and hyphens注释，避免升级覆盖。

5.2 故障现象：passwd: Authentication token manipulation error

表象：sudo passwd username输完新密码，报错Authentication token manipulation error。
根因定位：

• /etc/shadow文件系统只读（mount | grep " / "显示ro）；
• /etc/shadow权限错误（非640）；
• 磁盘空间满（df -h看/或/boot是否100%）；
• SELinux阻止写入（ausearch -m avc -ts recent | grep shadow）。

排查链路：

# 检查挂载状态 mount | grep " / " # 检查权限 ls -l /etc/shadow # 检查磁盘 df -h # 检查SELinux sudo sestatus # 如果enforcing，临时设permissive测试 sudo setenforce 0

根治方案：

• 只读挂载：sudo mount -o remount,rw /；
• 权限错误：sudo chmod 640 /etc/shadow && sudo chown root:shadow /etc/shadow；
• 磁盘满：sudo journalctl --disk-usage查日志占用，sudo journalctl --vacuum-size=100M清理；
• SELinux：sudo setsebool -P authlogin_nsswitch_use_ldap on（如果启用了LDAP）。

5.3 故障现象：adduser: The group "username" already exists.

表象：sudo adduser newuser报错说组已存在，但getent group newuser返回空。
根因定位：

• newuser组存在于/etc/group，但/etc/gshadow里没有对应条目；
• 或/etc/group里newuser组的GID被其他组占用（如newuser:x:1001:，但1001已被deploy组使用）。

排查链路：

# 查看/etc/group grep "newuser" /etc/group # 查看/etc/gshadow grep "newuser" /etc/gshadow # 查看GID冲突 awk -F: '$3==1001 {print $1}' /etc/group

根治方案：

• 删除残留组：sudo groupdel newuser；
• 或指定新GID：sudo adduser -g 1002 newuser；
• 预防：用groupadd -f（-f参数忽略已存在错误）。

5.4 故障现象：passwd: password unchanged（但明明输了新密码）

表象：sudo passwd username输两次新密码，提示password unchanged。
根因定位：

• 新密码与旧密码完全相同（pam_pwquality的difok=1要求至少1字符不同）；
• 或/etc/shadow里该用户密码字段是*或!（被锁定），passwd拒绝修改；
• 更隐蔽：/etc/shadow第二字段是NP（No Password），表示用外部认证（如LDAP），本地passwd无效。

排查链路：

# 查看shadow第二字段 sudo awk -F: '$1=="username" {print $2}' /etc/shadow # 如果是`*`、`!`或`NP`，则不能用passwd改 # 检查PAM配置是否启用LDAP grep "ldap" /etc/pam.d/system-auth

根治方案：

• 密码相同：输不同的密码；
• 账户锁定：先sudo passwd -u username解锁；
• LDAP认证：用ldapmodify或kinit改LDAP密码。

5.5 故障现象：adduser创建用户后，su - username报错Cannot execute /bin/bash: No such file or directory

表象：adduser成功，但切换用户失败。
根因定位：

• /bin/bash路径在目标系统不存在（如Alpine Linux用/bin/ash）；
• 或/bin/bash存在但权限为700（仅root可执行）；
• 或/bin/bash被chattr +i锁定（不可修改）。

排查链路：

# 检查shell路径 ls -l /bin/bash # 检查属性 lsattr /bin/bash # 检查是否在/etc/shells里 grep "/bin/bash" /etc/shells

根治方案：

• 改用系统真实shell：sudo adduser -s /bin/sh username；
• 修复权限：sudo chmod 755 /bin/bash；
• 解锁：sudo chattr -i /bin/bash。

5.6 故障现象：passwd改密码后，SSH仍提示Permission denied (publickey)，不问密码

表象：sudo passwd username成功，但ssh username@vps-ip还是只认密钥。
根因定位：

• /etc/ssh/sshd_config里PasswordAuthentication no；
• 或/etc/ssh/sshd_config里AuthenticationMethods publickey,password未启用；
• 或/etc/pam.d/sshd里auth [success=done default=ignore] pam_succeed_if.so user ingroup nopasswdlogin跳过了密码验证。

排查链路：

# 检查sshd配置 sudo grep "PasswordAuthentication" /etc/ssh/sshd_config # 检查PAM配置 sudo grep "auth.*pam_succeed_if" /etc/pam.d/sshd # 重载sshd sudo systemctl restart sshd

根治方案：

• 设PasswordAuthentication yes；
• 注释掉/etc/pam.d/sshd里干扰行；
• 测试：ssh -o PubkeyAuthentication=no username@vps-ip。

5.7 故障现象：adduser后用户家目录权限为755，导致ssh拒绝登录

表象：adduser成功，但ssh username@vps-ip报错Permissions 0755 for '/home/username/.ssh/authorized_keys' are too open。
根因定位：

• adduser创建家目录时，/etc/adduser.conf里DIR_MODE设为0755（默认是0755，但ssh要求0700）；
• 或/etc/skel/.ssh目录权限是755，被复制过去。

排查链路：

# 查看DIR_MODE grep "^DIR_MODE" /etc/adduser.conf # 查看skel权限 ls -ld /etc/skel/.ssh

根治方案：

• 改DIR_MODE=0700；
• 修复现有用户：sudo chmod 700 /home/username && sudo chmod 600 /home/username/.ssh/authorized_keys；