1. 先把问题分层JumpServer 里的忘记密码和用户锁定到底有几种JumpServer 登录密码忘记、用户被锁定这两件事在运维群里被问到的频率高得离谱。我前后搭过七八套 JumpServer从 v2.7 一路跟到 v3.x中间帮同事处理过不下三十次类似的求助最后发现绝大多数人卡住不是因为问题有多难而是一开始就没分清自己遇到的是哪一类问题。有人是普通用户忘了自己的登录密码有人是管理员账号自己进不去了还有人其实是登录后端资产时被目标主机的锁定策略拦住了另外一部分人只是被 JumpServer 自身的登录失败次数限制挡住了。这四种情况看起来都是登不上处理路径却完全不同用错方法不但解决不了还可能把原本能救的账号彻底搞死。我做这件事的顺序很固定先判断是谁的账号再判断是被 JumpServer 拦的还是被操作系统拦的最后才决定用 Web 界面、命令行还是数据库兜底。这套判断逻辑一旦形成条件反射处理这类问题的平均时间能从半小时压到三分钟以内。下面我会把每个环节的机制、参数和实操命令都摊开讲包括那些官方文档里不太会写、但线上真能救命的细节。1.1 四类高频场景速览先把场景列清楚你对号入座就行。第一类是普通用户忘记登录密码账号本身没问题只是口令想不起来了这类最好处理管理员在后台点几下就能重置。第二类是账号被登录限制锁定密码其实是对的但前面连续输错几次触发了锁定策略账户在某个时间窗口内拒绝任何认证请求。第三类是唯一的超级管理员账号进不去没人能帮你重置只能从命令行或者数据库层面动手。第四类是纳管资产侧的账号被锁JumpServer 本身登录正常但一连接目标服务器就提示认证失败或者账号锁定这个问题其实发生在被管的那台机器上JumpServer 只是把错误信息转发给你看。这四类里最容易误判的是第二类和第四类。前者你会以为自己密码记错了反复重试结果锁定时间不断刷新越试越锁后者你会跑去 JumpServer 后台翻半天其实后台一切正常问题在对面那台 Linux 或 Windows 主机上。我见过不止一个同事在这两个坑里来回打转最后把 JumpServer 的配置改得面目全非。提示判断第一优先级永远是到底是谁拒绝了这次认证。看报错来源如果页面停在 JumpServer 登录页问题在本体如果能进 JumpServer只是打开终端时报错问题在资产侧。1.2 为什么 JumpServer 的密码问题比普通系统更绕普通 Linux 机器忘了密码单用户模式进去改一行就完事。JumpServer 不行因为它本身是一个多层结构的应用你的登录请求要穿过 Web 前端、Core 服务、认证后端最后落到数据库或者外部认证源上。任何一层出问题表现出来的都是登录失败。更麻烦的是认证源可以有多套。JumpServer 支持本地认证、LDAP、AD、OIDC、CAS 等等一个用户可能同时存在于多个源里。如果这个用户是从 LDAP 同步过来的你在 JumpServer 后台给他重置密码同步任务一跑就被覆盖回去了用户还是登不上你会觉得改了没用。这种情况我遇到过两次第二次才反应过来是同步策略的问题第一次白白折腾了一个下午。再叠加一层 MFA多因素认证复杂度还会再上一个台阶。密码对了但动态口令丢了表现出来也是登录失败而处理方式又是另一套。所以处理 JumpServer 的密码问题本质上是一个先定位认证链路、再选择处理层的排查过程而不是简单地找个地方改字符串。2. 动手前必须搞懂的几件事认证链路与锁定机制动手之前花五分钟把机制搞清楚后面能少走很多弯路。这一节讲的东西看起来偏理论但每一条都直接决定了你该敲哪条命令。2.1 JumpServer 的登录认证走的是哪条路JumpServer 的认证流程大致是这样浏览器提交用户名密码到 Core 服务Core 根据该用户的source字段判断认证来源。如果是local就用数据库里存的哈希去比对如果是ldap或ad就转给对应的认证后端去校验JumpServer 数据库里根本不存这个用户的密码。这一点非常关键。你打开用户列表点开某个用户详情能看到一个来源字段本地用户显示本地目录服务同步过来的会显示对应的源名称。只要来源不是本地你在 JumpServer 里做的任何密码操作都是无效的正确做法是去源目录里改改完等同步或者手动触发同步。密码本身在数据库里存的是 Django 的 PBKDF2-SHA256 哈希格式长这样pbkdf2_sha256$迭代次数$盐值$哈希值。这意味着你没法直接在数据库里填一个明文或者自己算的哈希进去手写这个格式几乎必然出错。所有绕开应用层直接改数据库密码的尝试我都不建议除非你已经确认前面所有方法都失效了。登录成功之后JumpServer 会建立一个会话并在 Redis 里记录相关状态。会话有效期内你不需要重复认证所以有些用户改完密码发现自己还登着以为没生效其实会话还没过期而已退出重登就正常了。2.2 登录锁定是怎么被触发的JumpServer 的登录限制逻辑在系统设置里的安全设置板块v3.x 的界面路径大致是系统设置 → 安全设置 → 登录限制。核心参数有几个统计周期、失败次数上限、超过上限后的锁定次数阈值、锁定持续时长。这四个参数配合起来决定了一个账号会不会被锁、锁多久。它的判断逻辑是在统计周期内统计某个账号或某个来源 IP的连续认证失败次数达到阈值就触发锁定锁定时长内该账号的登录请求一律拒绝包括密码正确的情况。这个设计本身是为了挡暴力破解但它对正常用户的杀伤力也不小尤其是那种密码记混了反复试的人。在配置文件层面这些参数写在 JumpServer 安装目录下的config.txt里常见的字段名大致是SECURITY_LOGIN_LIMIT_ENABLED、SECURITY_LOGIN_LIMIT_COUNT、SECURITY_LOGIN_LIMIT_TIME、SECURITY_LOGIN_LIMIT_LOCK_TIME这一组。不同小版本的字段名可能会有差异以你本地config.txt里的实际内容为准改之前先备份一份。注意config.txt改完之后必须执行./jmsctl.sh restart才会生效直接改文件不重启是最常见的改了没反应原因。改之前请先cp config.txt config.txt.bak。2.3 密码策略与 MFA 的相互作用还有一组参数容易被忽略就是密码复杂度策略最小长度、是否要求大写、小写、数字、特殊字符、密码有效期、历史密码数量限制。这些参数本身不直接导致锁定但会间接制造麻烦。举个例子你给用户重置了一个不符合当前复杂度要求的新密码用户拿到后去登录JumpServer 可能会强制要求他先改密码才能进入系统用户改了又忘记规则觉得麻烦反复试错最终触发锁定。另一个常见情况是密码有效期到期用户被强制改密改的时候又被复杂度规则拦住来来回回就锁了。MFA 的关系更直接。如果管理员在系统设置里开启了强制 MFA所有用户登录时都必须输入动态口令。用户的手机丢了、换机了、绑定的 App 卸载了都会导致他虽然有正确密码也进不去。这种情况下用户看到的提示不是密码错误而是要求输入验证码很多人会误以为自己密码记错了在那里反复输密码然后触发登录锁定。这两个问题叠加排查难度就翻倍了。我的建议是日常运维中把 MFA 的重置能力牢牢掌握在自己手里同时保留至少一个不使用 MFA 的应急管理员账号这个账号的密码用密码管理器保存好平时不用只在救火时动用。3. 普通用户忘记密码能自己搞定的两条路普通用户忘记登录密码是整个问题域里最好处理的一类。这里分两条路管理员帮着重置以及用户自助找回。两条路的适用条件不一样下面分别说。3.1 管理员后台一键重置管理员登录 JumpServer 之后进入用户管理 → 用户列表找到目标用户点进去或者用操作列的更多菜单会看到重置密码的入口。v3.x 里这个入口在用户详情页比较显眼的位置点开之后输入新密码即可。这里有个细节重置密码的时候系统会根据当前生效的密码策略校验新密码如果不符合复杂度要求会直接报错。所以要么按策略给一个合规的密码要么先去系统设置里看当前的策略是什么。我一般会准备一个符合常见策略的临时密码模板比如「平台名 年份 特殊符号 数字」重置之后口头告知用户并让他立刻改掉。重置完成之后不需要重启任何服务用户立刻就能用新密码登录。但要注意如果这个用户的来源不是本地重置操作要么会被拒绝要么会被下一次同步覆盖。我在实操中养成的习惯是点开用户详情先扫一眼来源字段确认是本地再动手。另一个坑是codeis_active/code和有效期这两个字段。有些账号被重置了密码还是登不上最后发现是账号被停用了或者设置了过期时间已经到期。这两项在用户详情页里都能看到和修改重置密码的时候顺手检查一遍能省掉一次来回。3.2 用户自助找回邮件与短信通道JumpServer 支持用户通过忘记密码链接自助重置前提是管理员已经在系统设置里配置好了邮件服务器或者短信网关。这个功能配置起来不算复杂但有几个地方容易翻车我踩过至少两次。第一次是邮件服务器的配置问题。SMTP 主机、端口、账号、密码、是否使用 TLS这几项任何一项填错都会导致发送失败而且失败日志不一定显眼。建议配置完成之后在系统设置里找发送测试邮件的按钮先把通道打通再开放给用户。第二次是用户的邮箱字段压根没填。批量导入用户的时候如果只填了用户名邮箱是空的用户点找回密码系统找不到收件地址直接失败。所以我一般会在导入模板里强制要求邮箱这一列必填导入之后抽查几个确认无误。提示自助找回功能的入口默认可能在登录页的忘记密码链接上。如果公司内网无法收外网邮件建议配置内部邮件中继别依赖公网邮箱否则大量用户同时找回会触发频控。3.3 LDAP 或 AD 同步用户为什么改不了密码这是被问得最多的一个。用户的来源字段显示为 LDAP你在 JumpServer 后台怎么点都改不了他的密码或者改了之后过一段时间又失效了。原因很简单JumpServer 不存这类用户的密码哈希。用户登录时提交的密码会直接转发给 LDAP 或 AD 服务器去校验JumpServer 只负责接收校验结果。你在 JumpServer 侧做的任何密码修改要么被忽略要么同步任务一跑就被覆盖。正确做法是去目录服务里改。用域管理员账号在 AD 用户和计算机里重置该用户密码或者用 LDAP 管理工具修改userPassword属性。改完之后用户直接就可以登录 JumpServer 了因为每次登录都会实时去源里校验不需要等同步。同步任务同步的只是用户属性比如姓名、邮箱、部门密码不在同步之列。有一类特殊情况需要留意有些企业配置了 LDAP 和本地认证共存用户来源字段可能因为配置变更而改变。如果你发现某个用户昨天还能本地改密码今天改不了先去看看来源字段有没有变化别急着怀疑系统出 bug。4. 账号被锁定等、改、清三招账号锁定比忘记密码更让人火大因为密码明明是对的。这一节把处理逻辑理顺你会发现其实就三招等它自动解锁、改策略缩短或调整锁定窗口、清掉 Redis 里的失败计数。4.1 确认是不是真的被锁定了首先得确认。JumpServer 在登录失败达到阈值后通常会给出明确提示比如账户已被锁定请稍后重试或者类似的文案。如果你看到的只是用户名或密码错误那大概率还是密码问题不是锁定。这一点很关键因为这两种情况处理方式完全不同。还有一种隐蔽情况某些版本在锁定期间返回的提示和密码错误提示一模一样用户就以为自己是记错了。这时候你可以换个角度验证用同一个账号在另一台机器、另一个浏览器上试一次如果还是同样提示那就八成是锁了或者直接找管理员看后台的登录日志JumpServer 的审计日志里能看到登录尝试的记录和来源 IP。如果是生产环境我建议直接在 Core 容器里看日志比翻界面快docker exec -it jms_core bash tail -f /opt/jumpserver/logs/jumpserver.log日志里搜索该用户名能看到login limit或者locked相关的记录确认是否触发了登录限制。4.2 调整登录限制参数确认是被自身策略锁了之后第一步是评估当前参数是否合理。默认的失败次数阈值一般比较保守比如统计周期十分钟内失败五次就锁锁定半小时。对于密码记性差一点的同事这个阈值确实有点严。调整的地方有两个一个是 Web 界面的系统设置一个是config.txt。我个人的习惯是只改配置文件因为界面改的东西在升级或者重装时容易丢配置文件至少有据可查。改的具体内容大致是适当放宽统计周期内的失败次数、缩短锁定持续时长。放宽多少要看你们公司的安全要求我不建议把失败次数放到十次以上那样暴力破解防护形同虚设。改完之后必须重启生效cd /opt/jumpserver-installer-v3.x.x ./jmsctl.sh restart重启过程中正在使用的会话会中断所以务必挑业务低峰期做最好提前在群里知会一声。这个操作我做过很多次整体很稳但确实会断连别在有人跑批量脚本的时候搞。4.3 清理 Redis 里的失败计数有时候你不想改全局策略只想把某个人立刻放出来。这种情况下光调参数没用因为已经累计的失败计数还在缓存里得清掉。JumpServer 的登录失败计数存在 Redis 里。操作方式是先进 Redis 容器docker exec -it jms_redis redis-cli如果配置了 Redis 密码先执行AUTH 你的密码。密码在config.txt里的REDIS_PASSWORD字段。认证通过后用INFO keyspace看看各个库的 key 分布再切到对应的库SELECT 0 INFO keyspace KEYS *limit*慢慢排查找到和登录限制相关的 key确认之后再删除。这里必须强调先 KEYS 看一眼确认了再 DEL千万别上来就FLUSHDB。Redis 里除了登录计数还有会话、Celery 任务队列等一堆东西清了会出大问题。我就见过有人图省事直接清库结果所有在线会话全掉任务队列清空忙活一晚上。清完 key 之后用户立刻就能登录不需要重启服务。这是这几招里最快的一种。5. 管理员账号也进不去了命令行与数据库兜底方案这是最棘手的一类。整个系统就一个超级管理员密码忘了没有任何人能帮你从界面重置。这时候只能走命令行。好消息是JumpServer 提供了非常顺手的工具整个过程比想象中简单。5.1 进容器用 changepasswordJumpServer 基于 Django所以 Django 自带的changepassword命令可以直接用。容器化部署的情况下执行顺序是这样docker exec -it jms_core bash cd /opt/jumpserver/apps python manage.py changepassword admin回车之后会提示你输入新密码并确认。这里要注意changepassword会走一遍密码校验逻辑如果新密码不符合当前的复杂度策略会被直接拒绝并给出提示。这其实是好事避免你设一个不合规的密码导致下次登录又被要求改。如果你输的密码一直被拒而你又急着进去可以临时把密码策略放宽。策略在系统设置的安全设置里能改改完再执行一次changepassword进去之后再把策略调回去。但我更推荐的做法是直接把密码设成符合现有策略的比如策略要求八位以上含大小写和数字那就给一个这样的密码别去动策略动来动去容易忘。还有一个细节如果你的部署不是 Docker 方式而是源码部署或者其他方式路径会不一样。源码部署一般是进到 JumpServer 的安装目录找apps文件夹命令是一样的。先用find / -name manage.py找一下位置确认路径再执行。5.2 用 Django shell 直接改changepassword偶尔会碰到一些奇怪的问题比如密码策略校验卡住、命令报错。这时候可以用 shell 绕过docker exec -it jms_core bash cd /opt/jumpserver/apps python manage.py shell进去之后执行from users.models import User u User.objects.get(usernameadmin) u.set_password(你的新密码2024) u.is_active True u.save()这段代码有几个好处。一是set_password会正确生成 Django 需要的哈希格式不会出错。二是顺手把is_active置为 True避免账号其实是被停用导致的登不上。三是整个过程不受密码策略校验的干扰你想设什么就设什么当然安全起见还是设复杂点。如果连用户名都不确定可以先把管理员列出来User.objects.filter(is_superuserTrue).values_list(username, is_active, date_expired)看一眼哪些是超级管理员、有没有被停用、有没有过期。这个列表我在处理别人的烂摊子时经常用很多进不去的案例其实是账号过期了改完密码照样进不去最后才发现是date_expired到点了顺手把日期往后延就行。注意改完之后一定要u.save()光调用set_password不保存是不写库的。这个低级错误我自己犯过一次改完密码发现没生效回去看日志才发现漏了保存。5.3 数据库层面查看与 DBeaver 的用法有些不那么紧急的场景比如你想批量核对一批用户的状态用数据库客户端会方便很多。JumpServer 默认使用 PostgreSQL 作为后端数据库容器名一般是jms_core配套的数据库容器。你可以用 DBeaver 这类通用数据库客户端直连。连接信息从config.txt里找DB_HOST、DB_PORT、DB_NAME、DB_USER、DB_PASSWORD。默认端口一般是 5432库名通常是jumpserver。连上之后打开users_user这张表能看到所有用户字段包括username、password、is_active、is_superuser、date_expired、source等等。这张表我最常看的几个字段就是上面那几个。比如排查为什么这个用户登不上一眼扫过去is_active是不是 falsedate_expired是不是过期了source是什么来源。这三个问题能覆盖相当大比例的故障。但这里必须划一条红线不要用 DBeaver 直接 UPDATEpassword字段的值。前面说过这个字段存的是 PBKDF2 哈希格式是pbkdf2_sha256$迭代次数$盐值$哈希值迭代次数和盐值都是随机的你没法手工构造一个正确的值。我见过有人从别的系统复制一段哈希过来粘贴结果那个账号彻底废了最后只能用 shell 重置。DBeaver 在这个场景里的定位是查看和核对改密码请回到manage.py那条路。5.4 MFA 设备丢了怎么处理如果账号开了 MFA密码改对了也进不去,因为登录时会要求输入动态验证码。用户手机丢了、换了、认证 App 卸载了都需要重置 MFA。最简单的情况是用户还能登录比如他用备用码进去了那他自己在个人信息页里可以解绑重新绑定。麻烦的是完全进不去的情况。JumpServer 的 MFA 实现基于 django-otp 这套库。管理员可以直接用 shell 把某个用户的 MFA 设备记录删掉docker exec -it jms_core bash cd /opt/jumpserver/apps python manage.py shellfrom django_otp.plugins.otp_totp.models import TOTPDevice TOTPDevice.objects.filter(user__username目标用户名).delete()删完之后该用户的 MFA 绑定就没了他用密码就能登录进去之后重新绑定即可。这个操作我做过几次非常干净不会影响其他用户。执行之前建议先查一下有哪些设备记录TOTPDevice.objects.filter(user__username目标用户名).values(id, name, confirmed)另外v3.x 的用户详情页里也提供了重置 MFA 的按钮如果你已经能用管理员账号登录直接在界面点就行不用进命令行。命令行方案主要留给管理员自己也丢了 MFA这种极端情况。6. 另一类用户锁定纳管资产侧的账号被锁前面五节讲的都是 JumpServer 本体的问题。但实际工作中还有一大类求助是JumpServer 能登上但一连服务器就报账号锁定。这类问题的战场根本不在 JumpServer 上而在被管的那台机器上。热词里提到的统信 UOS 根用户锁定、麒麟用户锁定说的就是这一类。6.1 Linux 系的解锁faillock 与 pam_tally2 的区别主流 Linux 发行版的登录失败锁定机制这几年经历了一次换代。老一些的系统比如 CentOS 7用的是pam_tally2模块计数记录在/var/log/tallylog文件里新一些的系统换成了pam_faillock模块计数放在/var/run/faillock/目录下。用错命令是解不开锁的这是最常见的一个坑。先判断系统用的是哪套。你可以直接看 PAM 配置文件grep -r faillock\|tally /etc/pam.d/如果输出里出现pam_faillock.so就用 faillock 系的命令出现pam_tally2.so就用 tally2 系的命令。faillock 系的查和解faillock --user root faillock --user root --reset第一条是查看该用户的失败记录会列出每次失败的时间、来源终端等信息第二条是清空记录执行完账号立刻解锁。faillock 的策略配置在/etc/security/faillock.conf里常见参数是deny允许失败次数和unlock_time锁定秒数。如果unlock_time设为 0表示必须管理员手动解锁不会被自动放出来。tally2 系的查和解pam_tally2 -u root pam_tally2 -u root -r-r是 reset效果和 faillock 的--reset一样。策略配置在/etc/pam.d/system-auth或者/etc/pam.d/password-auth里参数形如deny5 unlock_time600。统信 UOS、银河麒麟这类基于 Linux 的发行版机制是一样的只是默认策略可能更严一些比如连续失败三次就锁而且unlock_time可能是 0也就是只能手动解。我处理过一台统信服务器root 被锁了之后等了一整天都没自动解开最后就是靠faillock --user root --reset解决的。所以遇到国产化环境先去确认它的 PAM 用的是哪套模块别照搬网上的教程。还有一点要提醒如果/etc/security/faillock.conf里的unlock_time是 0那么用户被锁之后无论等多久都不会自动解锁必须手动 reset。这种情况在处理时要顺手把策略调一下不然下次还得来一遍。当然如果公司安全基线强制要求这样配那就老老实实保留但要把解锁流程写进应急手册。6.2 Windows 与域账号的解锁Windows 资产的锁定分两种情况本地账号和域账号。本地账号的锁定策略在本地安全策略里配置默认可能不启用或者阈值很宽。解锁本地账号最直接的方式是通过计算机管理界面找到本地用户和组打开该用户属性里面有一个账户已锁定的复选框取消勾选即可。命令行方式本地账号可以用 ADSI 接口操作 PowerShell$user [ADSI]WinNT://./目标用户名,user $user.IsAccountLocked 0 $user.SetInfo()域账号则是另一套。域环境下的锁定策略由组策略统一管理默认可能失败五次锁半小时。解锁需要用域管理员权限执行Unlock-ADAccount -Identity 目标用户名这条命令需要装有 RSAT 工具的机器或者在域控上直接执行。查状态用Search-ADAccount -LockedOut可以列出所有被锁的域账号批量处理时很好用。热词里还提到Win11 修改登录密码提示此功能需要移动介质这其实是另一码事通常是本地账户的密码重置盘策略或者 UAC 相关限制导致的跟账号锁定无关。遇到这个问题先确认当前用的是微软账户还是本地账户两种账户的改密路径不同本地账户可以走net user 用户名 新密码这条路微软账户只能联网改。6.3 从 JumpServer 侧避免把资产账号弄锁资产侧账号被锁很多时候不是用户自己试错的而是JumpServer 在背后自动重试造成的。这一点特别值得说。JumpServer 连接资产时会用配置在资产或资产账号里的凭据去认证。如果这个凭据是错的而你又反复点连接每次尝试都是一次失败认证很容易在短时间内把资产上的账号锁掉。更隐蔽的是自动化的任务比如定期改密任务、定期巡检任务如果配置的旧密码不对这些任务会周期性地去尝试认证不知不觉就把账号锁了。我遇到过一次某台服务器重启后定期改密任务失败重试一晚上把 root 试锁了第二天上班才发现。规避方法有这么几条。第一新建资产账号时先用系统自带的 ssh 或 rdp 客户端手工验证一次凭据确认无误再往 JumpServer 里填。第二定期改密任务上线前先在测试环境完整跑一遍流程确认新密码推送成功、旧密码失效再放到生产。第三给关键资产的账号留一条后路比如配置一个专用的运维账号作为备用主账号被锁时还能用备用账号进去解锁。还有个小技巧在 JumpServer 里配置资产时尽量用密钥认证而不是密码认证。密钥不存在失败计数也就不会触发锁定。对于必须用密码的老系统可以考虑在资产上把该账号的失败锁定策略放宽或者设置一个足够长的自动解锁时间减少人工解锁的频率。7. 常见问题排查速查与踩坑记录前面讲了原理和路径这一节把高频报错和对应的处理方式整理成表方便你现场翻。后面再补几条我认为最值钱的经验。7.1 报错对照表现象大概率原因处理方式登录页提示密码错误多次后提示锁定触发登录限制等待解锁或清 Redis 失败计数或调整策略提示密码错误但用户坚称密码没错账号来源是 LDAP/AD本地改的密码不生效去源目录改密码密码正确但要求输入动态验证码已绑定 MFA设备丢失删除 TOTPDevice 记录或后台重置 MFA改完密码提示不符合策略新密码不满足复杂度要求按策略重设或临时放宽策略后恢复管理员账号输密码无反应或者不报错账号被停用或已过期shell 里置is_activeTrue延期date_expired能登 JumpServer连资产提示账号锁定资产侧本地锁定策略触发去资产上执行 faillock / pam_tally2 解锁修改配置文件后无变化未重启服务执行./jmsctl.sh restart批量用户收不到找回密码邮件SMTP 配置错误或用户邮箱为空发测试邮件验证补全用户邮箱这张表覆盖了大约八成的现场问题。剩下两成通常是环境特有的坑比如容器名被改过、端口被占用、升级后配置项改名等等那就得看日志了。7.2 几条我认为最值钱的经验第一条永远给自己留第二个超级管理员。JumpServer 初次部署时只有一个 admin 账号默认密码是公开的登录后会强制你改。我见过太多人改完之后没记录过了半年自己都忘了。正确做法是部署完立刻建第二个管理员账号用不同的密码策略密码存在团队共享的密码管理器里两个人以上知道。这样即便一个人出事另一个人能顶上。第二条配置变更前先备份config.txt。这个文件基本上决定了 JumpServer 的全部行为改错了会很麻烦。养成cp config.txt config.txt.$(date %Y%m%d)的习惯出问题直接换回来。我靠这个习惯回滚过至少三次误操作。第三条清理 Redis 之前一定先 KEYS。这个坑我前面强调了这里再说一次因为它造成的破坏是全局性的。FLUSHALL和FLUSHDB这两个命令在没有确认库里存了什么之前永远不要敲。第四条别用数据库客户端改密码哈希。DBeaver 这类工具适合查看和核对状态字段不适合直接写password字段。改密码请一律走manage.py这是唯一能保证哈希格式正确的路径。第五条把解锁流程写进值班手册。资产侧的锁定解法和 JumpServer 本体的锁定解法完全不同值班的人如果只会一种遇到另一种就会卡住。手册里写清楚先判断是谁拒绝的认证再按表格对号入座附上具体命令。我们团队加了这一页之后这类求助的处理时长明显降下来了夜班同事也不用再来回问了。最后分享一个我自己反复用的小办法准备一个文本片段里面放好changepassword、set_password、TOTPDevice删除、faillock --reset这几段命令用的时候改个用户名就能执行。不是为了偷懒而是这些命令平时用不到真要用的那一刻往往是着急的时候手打容易出错有现成的片段贴过去最稳。