先给大家一个结论：在 Docker 容器里改 root 密码这件事，说难不难，但它和你在物理机、虚拟机里改密码的思维方式完全不一样。网上大量“照着改完还是不行”的求助帖，十有八九不是命令敲错，而是没搞清楚容器的文件系统、进程模型和镜像分层机制。我这两年被各类容器环境折腾过不少次，踩过一些坑才把这块捋顺，这篇就把完整的方法、背后的原理、踩过的坑一次说清楚。
开门见山，容器里修改 root 密码的标准动作就两条：用docker exec进入容器，然后执行passwd root。但这样改完的结果通常只在容器“存活期间”有效，一旦容器被删或者基于镜像重新创建，密码就会还原。想让它持久生效，需要把改动固化到镜像里，或者按容器的一贯思路——不要在容器里做这种“事后登录”操作。下面展开讲。
1. 想改得对，先把容器的“密码到底放在哪”搞清楚
1.1 容器不是精简版虚拟机
很多人第一次接触容器，下意识把它当成一个跑起来的精简 Linux 虚拟机，于是沿用虚拟机习惯去管理：ssh 进去、改密码、装包、写配置，然后希望这个状态一直保留。
这是最大的误区。容器本质上是宿主机上的一个隔离进程，它复用的是宿主内核，所谓“系统”只是一套根文件系统、进程空间、网络栈和挂载视图的集合。你执行passwd root，修改的是容器可写层的/etc/shadow文件。可写层是临时的，它跟着容器生而生、死而死。
类比一下：虚拟机里的改动写的是虚拟磁盘，相当于你给一台硬盘上的文件做持久保存；容器里的改动写的是当前运行实例的临时便签，容器停止后便签还在，但容器被docker rm删掉，便签就丢了。就算不删容器，只要用原来的镜像重新docker run一个，新容器又是一张干净的白纸。
所以无论你用什么方法改密码，第一步要清醒认识到：改密码不是问题，让改动能“留下”才是问题。
1.2 镜像分层里根本没有“密码”这一说
Docker 镜像由只读层构成，每一层是 Dockerfile 里一条指令的结果。容器启动时，Docker 在只读层之上挂载一个可写层。所有运行时修改都落在这个可写层。
读取文件时是自顶向下找，可写层优先；但底层只读文件永远不可能被直接改动。因此/etc/shadow本身属于镜像某一层，容器内passwd只是把新内容“覆盖”到了可写层。看到的现象是文件内容变了，本质上是旧文件被隐藏、新文件补在顶层。
理解了这一点，就能解释各种诡异现象：容器创建之后你明明用ls -l /etc/shadow看到时间戳变了，但一重启容器又变回原样；或者你对一个运行中的容器执行docker commit提交镜像后，密码才真正被固化到新的镜像层级里。
1.3 所以“很快改完”的方案，通常延后处理
讲个小场景：某个临时调试容器，我只是想快速验证某个服务，需要把 root 密码改成一个已知值然后进去处理问题。这种情况直接docker exec改就行，重启丢了我也不在乎，因为容器本来就是临时的。
但如果是生产环境里的非常规容器，比如别人交付的镜像、从压缩包导入的镜像，里面没有提供应用启动入口，必须临时拿到 root shell 排查问题，那又要另说。这时你需要的不是“改密码”，而是“绕过密码问题，拿到 shell”——这涉及--entrypoint覆盖、docker commit备份现场等一系列操作，下面会专门讲。
1.4 这里说的 root 是系统账号，不是数据库账号
还要提示一下，很多人在容器里改了系统 root 密码，然后连接 MySQL、MariaDB 还是报ERROR 1045 (28000): Access denied for user 'root'@'localhost'，于是怀疑自己密码没改成功。这完全是两码事。系统 root 对应的是/etc/shadow，MySQL 的 root 对应的是库内部的mysql.user表。数据库容器的连接认证根本不会去读系统密码文件，后文我会给这类场景单独列一段。
2. 修改容器 root 密码的标准操作流程
2.1 前提：先确认容器状态和进入方式
动手之前，先确认两个事实：容器在不在运行，容器里有没有可用的 shell。
# 查看所有容器 docker ps -a # 输出示例 # CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES # a1b2c3d4e5f6 ubuntu:22.04 "bash" 2 hours ago Up 2 hours test-web容器在运行，直接进入：
docker exec -it test-web /bin/sh为什么推荐/bin/sh而不是/bin/bash？因为很多官方精简镜像、Alpine 镜像、基于 distroless 的镜像里根本不存在 bash。sh是 POSIX 标准 shell，绝大多数镜像都带。进去以后先验一下身份：
id whoami输出是uid=0(root)就行，如果不是，说明容器默认不是 root 进入，可以显式指定用户：
docker exec -u 0 -it test-web /bin/sh-u 0等价于--user root，在 exec 层面强制以 UID 0 进入，避免容器内普通用户没有权限改/etc/shadow。
2.2 用 passwd 修改密码的正确姿势
进入容器后，执行：
passwd root系统会提示输入两次新密码，注意输入时不会回显，这是正常现象。看到passwd: password updated successfully就是成了。如果你所在镜像里没有passwd这个命令，会有两种常见情况，下面单说。
如果输入passwd时报错command not found，大概率是精简镜像。Ubuntu/Debian 系可以现场装：
apt-get update apt-get install -y passwdAlpine 系用：
apk add shadow装完再执行passwd root。注意，装包这个动作同样发生在可写层，不持久。
还有一种不需要passwd命令、直接通过修改文件实现密码重置的方法：
docker exec -u 0 -it test-web /bin/sh echo 'root:你的新密码' | chpasswdchpasswd会帮你生成符合当前系统策略的密码哈希并写入/etc/shadow，比手动构造哈希安全得多。但要确认镜像里有chpasswd；不一定都有，没有就装passwd。
如果连包管理器都没有，那就只能备份原始/etc/shadow，用宿主机生成的哈希替换。宿主机上执行：
openssl passwd -6 '你的新密码' # 输出形如 $6$randomsalt$...的哈希然后在容器内用编辑器或者sed替换 root 行。这个方法相当不推荐，非常容易搞坏 shadow 文件语法，只作为兜底手段。
2.3 “改密码”这个动作怎么让它持久生效
一次性调试的话，上面提到的方法就到头了。如果希望容器删除重建后密码仍有效，三条路可选。
第一种，最快最暴力：docker commit把当前容器固化成新镜像。
docker commit test-web my-image-with-new-pass:1.0以后基于my-image-with-new-pass:1.0创建容器，密码就是你改完的状态。这个方案适合应急，缺点也很明显：commit 会把容器在当前状态下的所有可写层差异全部固化，包括临时文件、日志、误装的包，镜像体积膨胀且不可复现。能不用尽量不用。
第二种，规范做法：把密码设定写进 Dockerfile，重新构建。
FROM ubuntu:22.04 RUN echo 'root:MyNewPass123' | chpasswd构建：
docker build -t my-image:v1 .这种方式可重复、可见、可审计，我强烈推荐。唯一要注意的是固定密码不能明文出现在镜像层里，因为镜像会分发、会留存，任何能拿到镜像的人都可以通过docker history直接看到这一层。稳妥的办法是构架时用构建参数传进来：
ARG ROOT_PASS RUN echo "root:${ROOT_PASS}" | chpasswd然后：
docker build --build-arg ROOT_PASS='临时强密码' -t my-image:v1 .第三种：在应用初始化或入口脚本里动态设定密码，适合“每次启动必须重置密码”的场景。
#!/bin/sh echo 'root:动态密码' | chpasswd exec "$@"这种做法一般配合环境变量注入。但由于容器本身不提倡交互式登录，动态设密码的场景其实非常少。
3. 改完密码还是登不上？九成是这些原因
3.1 root 账户可能处于锁定或禁用状态
很多官方镜像默认设置下，root 没有密码，或者/etc/shadow中 root 的密码字段被设置为!或*，表示账户被锁定、无法通过密码登录。
你在容器里执行：
passwd -S root如果输出显示L、L K，说明锁着。先用：
passwd -u root解锁，然后再passwd root设置。很多“改了密码还是登不上”的报错，其实根因是这一步被跳过，shell 会话看起来一切正常，但认证层直接拒绝。
3.2 容器里跑 sshd，登录被拒的常见非密码项
在容器里安装 sshd，然后用密码从宿主机 ssh 进入，这是踩坑重灾区。密码明明改了，还是Permission denied或者卡在密码验证循环，排查顺序按下面来。
先看 SSH 服务本身有没有起来：
docker exec test-web service ssh status容器里通常没有 systemd，很多镜像也没有service命令。可以看进程：
docker exec test-web ps aux | grep sshd如果只有一个/usr/sbin/sshd进程，基本没问题；如果一条都没有，就是服务没启动。启动方式一般是：
/usr/sbin/sshd或者发行版配套的初始化脚本。
再看sshd_config关键项：
grep -E 'PermitRootLogin|PasswordAuthentication|UsePAM' /etc/ssh/sshd_config镜像默认配置往往不满足 root 密码登录需求，常见的坑是PermitRootLogin prohibit-password，意思是 root 只能通过密钥登录，密码无效。改成：
PermitRootLogin yes PasswordAuthentication yes然后重启 sshd。如果改完还不行，继续看/root目录权限和/etc/ssh/sshd_config里要求的密钥文件权限。OpenSSH 对权限很敏感，/root目录如果是 777，或者主机私钥权限太宽松，它宁可拒绝登录也不冒险。容器里没有chown root:root /root、chmod 700 /root这两个动作的话，容易被这类权限问题卡很久。
3.3 有的容器里“登录”根本不走 /etc/shadow
还有一种场景你也会遇到：容器映像用到了 NSS 或 PAM 的特殊配置，或者干脆是绕过系统认证的极简镜像。比如通过环境变量初始化好的应用容器，你改了系统 root 密码，但应用登录认证走的是自己的用户体系，与/etc/shadow无关。
在你动手改密码之前，先想清楚一个问题：你要进入容器做什么？是拿系统 shell，还是为了某个应用账号？如果只是拿 shell，其实不一定要密码——docker exec本身就是最高权限通道，它在容器内默认就是以 root 身份执行命令，根本不需要验证密码。你甚至完全不需要知道密码，也不需要改密码，就能拿到 shell。
这也是容器场景和传统服务器最大的区别：在宿主机能操作 Docker 的前提下，容器内密码的意义非常有限。
3.4 数据库容器里的 root 密码报错
前面提过，MySQL、MariaDB 这类容器里的“root”是数据库用户，不是系统用户。如果你是在容器的数据库客户端里执行ALTER USER，那是数据库层面。
docker exec -it mysql-container mysql -u root -p ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码'; FLUSH PRIVILEGES;常见的ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)和系统 root 密码没任何关系，别拿系统密码去试。MYSQL_ROOT_PASSWORD 是容器启动时通过环境变量传给 MySQL 初始化脚本的，它只在数据目录首次初始化时生效。如果你启动时忘了设，或者想改已有数据目录的管理密码，正确路径是先以--skip-grant-tables临时启动，然后去mysql.user表更新认证插件和密码哈希，再重启。这套流程跟改系统/etc/shadow完全不同，别混在一起。
4. 几个容易误判的“根因”排查经验
4.1 容器里 root 改密码提示无权或文件被占用
极少数情况，你会遇到改密码时提示/etc/shadow被占用、无法修改、或者执行passwd直接报错。这种多半不是权限问题，而是容器文件系统处于只读状态。
比如你用--read-only启动的容器，整个根文件系统是只读的：
docker run --read-only -it ubuntu:22.04 /bin/sh在这个容器里，你就算 uid=0，也没法写/etc/shadow。passwd会报cannot change password for root。
解决办法是临时把可写目录挂载进来，或者干脆放弃在容器内改，直接在宿主机上对文件做操作。
4.2 挂载目录权限错乱，root 也写不进去
有次我排查一个容器内应用报“Permission denied”，开发说镜像里明明设置了 root 权限，为什么宿主机挂载进去的目录应用写不了。
真相很简单：宿主机目录的所有者是宿主机 UID，比如 UID 1000。容器内进程是 UID 0，但共享挂载卷不经过容器用户命名空间映射时，UID 0 在宿主机看到还是 0，而目录 owner 是 1000，权限 755。root 理论上有系统权限，但在已挂载的宿主目录上，Docker 默认容器内 root 和宿主机 root 是同一个，需要绕过目录权限才能写。
常见解法有三种：
- 宿主机上放权：
chmod -R 777或者chown -R 1000:1000，图省事但不安全。 - 让容器以宿主机 UID 运行：
docker run -u 1000:1000，容器内进程变成和宿主文件 owner 一致的 UID。 - 利用
user namespace remap，把容器 root 映射到宿主机的普通用户。
这个问题和修改密码没有直接关系，但如果你在容器里登录后，以 root 身份执行各种操作都报“无权限”，先考虑是不是这个原因，别急着去翻密码。
4.3 Docker Desktop 的权限/环境问题不等于容器密码问题
Windows 或 macOS 下用 Docker Desktop，经常出现各种奇怪的报错文案，比如“应用程序-特定 权限设置并未向在应用程序容器中运行的地址发布 SID”“privileged access required”之类。这些报错是在 Docker 引擎层，发生在 Docker Desktop 的虚拟机与宿主交互过程中，你改容器 root 密码根本解决不了。
遇到这类问题，从几个角度查：Windows 下确认 Hyper-V/WSL2 的虚拟化支持正常，确认版本匹配；macOS 下看资源分配情况；权限类报错优先检查当前用户是否在 docker 用户组。用 Docker Desktop 顺手一点，但出现问题要会分辨层级：容器内密码、容器进程权限、Docker 引擎权限、宿主机权限，隔着一个大层次，别在错误的层上使劲。
4.4 密码过期策略造成“灵异登录失败”
容器如果是从基础镜像继承过来，而且做了企业级模板定制，可能对 root 设置了密码有效期。chage -l root可以看到最近一次更改时间、过期时间、失效时间。
要是镜像构建日距今很远，root 密码过期，登录时会提示密码过期并强制更改，自动化和脚本一旦无法交互，就会报错。解决办法是：
chage -M -1 root无限期有效，再执行chage -l root确认。这种坑在从长期没有更新的镜像派生的容器里很容易碰到。
4.5 容器内部时间漂移间接影响认证
容器默认和宿主机共享时钟，正常情况下不会漂移。但如果宿主机时间错误，或者镜像构建时的时区设置异常，会导致日志时间、证书校验时间错乱，服务会报“certificate expired”或“authentication failed”之类的误导信息。这不是密码问题，但容易被当成密码问题排查大半天。可以同步身份验证前先看一眼容器时间：
date -R如果时间明显不对，先纠正宿主机时钟，或者在容器内配置TZ环境变量规避显示差异。
5. 别把精力都花在“改密码”上，容器安全要这么管
5.1 安全加固优先考虑“不设密码”
容器设计哲学是应用即进程，运维入口主要是docker exec和编排工具，而不是 SSH 登录。所以正规生产镜像通常不启用 root 密码登录，甚至 root 的密码就是*、!锁定状态。
你要做的第一道加固是：容器里不启用密码认证。没有密码，就没有密码被爆破的风险。需要运维时，用docker exec进入，通过宿主权限控制谁有资格操作 Docker，而不是给每个容器都开一个 root 账户。
5.2 不要往镜像层里塞明文密码
我见过不少团队为了让容器能自动登录，把密码直接写进 Dockerfile：
RUN echo 'root:password123' | chpasswd这种做法最致命的地方在于密码会永久留在镜像历史层里。任何人拿到镜像，执行docker history就能看到。别以为后面用RUN rm -rf删掉文件就能掩盖，镜像层是叠加的，删除只是在高层标记，底层仍在。正确做法是用构建参数、环境变量、密钥管理工具，或者干脆不设密码。
5.3 应用不要一直跑在 root 下
很多人习惯不改密码的直接原因是容器里反正都以 root 跑。短期内省事，长期风险非常大。容器内 root 一旦被应用漏洞利用，权限提升路径比普通用户更直接。
合理的 Dockerfile 尾部应该加一段：
RUN useradd -r appuser -u 10001 USER appuser这样应用以普通用户运行，即使被攻破，也没有改系统文件的权限。如果你需要改密码，改成给非 root 用户设置密码可能还更合适。
5.4 控制容器运行特权，别随手 --privileged
还有一个和密码无关但息息相关的安全点：不要随手加--privileged。很多抱着“进容器里改密码”想法的同学，遇到权限问题习惯性用--privileged或--cap-add ALL解决，这下容器内的 root 在宿主机上等于超级管理员，直接干掉一整层隔离。为了在一个临时容器里改 root 密码，冒这种风险非常不值。
平时运行容器用默认 capabilities，需要特殊权限时精确加一两个，比如--cap-add NET_ADMIN，而不是 ALL。
5.5 定期做镜像扫描和最小化
容器里经常装着一堆没用的包，包括编辑器、工具链、sshd，这些都是攻击面。给容器设置 root 密码之前，问自己一句：这个容器需要交互登录吗？如果不需要，那最好连 shell 都不给，只暴露应用端口。
镜像扫描工具很多，我记得名字的有 Trivy、Grype、Clair，挑一个顺手能接入 CI 的就好。扫出来的“高危漏洞”里经常会有 openssh-server，因为它的版本迭代快。这个事实也侧面说明：容器里默认不要装 sshd，那玩意儿是给自己养了一头狼。
6. 最后分享一点我的实操习惯
如果你问我，在 Docker 容器里改 root 密码这件事，一个老手会怎么做？
我自己的习惯是：能不进去就不进去，能不改密码就不改密码。调试代码、看日志，全用docker exec直接跑命令；所有环境的配置差异，能通过挂载卷和环境变量解决的，绝不写死在镜像里；真要临时改一个容器的密码，我会先docker commit一个现场备份，再改，避免改坏以后无法恢复；如果是长期需要的密码变更，直接走 Dockerfile 重新构建，不给可写层留下永久依赖。
还有一个容易被忽略的小技巧：需要进入一个已经被配置成不运行 shell 的容器时，不必先把密码改好再进去，直接用docker run --rm -it --entrypoint sh 镜像名覆盖入口，就可以拿到一个干净的 shell。密码改不改，在这条路上根本不重要。
容器和虚拟机的最大差别就在这里——你不需要“登录”一个容器，你有的是更直接的手牌。把密码从习惯性操作中拿掉，你的容器安全等级会瞬间上一个台阶。
