⭐ 推荐:社区规则条款 V1.0

宝塔面板忘记登录密码怎么用 bt 命令重置?

lqyyzz
lqyyzz 观望站长
发布于 2026-10-28 02:26 ·7 浏览 ·12 回复
内容摘要

SSH 以 root 登录服务器后执行 bt,在菜单中选“修改面板密码”(7.x/8.x 多为序号 5),连输两次符合复杂度要求的新密码,再执行 bt restart 重启面板,即可不重装、不影响数据地重置宝塔面板登录密码。

SSH 用 root 登录服务器,输入 bt 回车,在菜单里选“修改面板密码”(多数 7.x/8.x 版本是序号 5),连输两次新密码即可完成重置;改完执行 bt restart 重启面板,新密码立即生效,用户名不变。

bt 命令重置宝塔面板密码的具体步骤是什么?

结论:整个流程只有 5 步,全程 1 分钟内完成,不需要重装面板、不会影响网站和数据库数据。

  1. 用 SSH 工具(Xshell、PuTTY、系统自带终端均可)连接服务器公网 IP 的 22 端口,用 root 账号登录。如果当前是普通用户,先执行 sudo -i 切到 root,因为 bt 命令只对 root 有效。
  2. 直接输入 bt 并回车,屏幕会列出宝塔命令行管理菜单,包含重启面板、停止面板、修改面板密码、修改面板用户名、强制修改 MySQL 管理密码等选项。
  3. 输入“修改面板密码”对应的序号并回车。宝塔 7.x 和 8.x 中该项通常是 5,所以很多人直接敲 bt 5 也能一步到位;但不同版本菜单编号会调整,以你屏幕上实际显示的序号为准最稳妥。
  4. 按提示输入两遍新密码。密码需满足复杂度校验,长度 8 位以上,包含字母、数字、特殊字符组合,过于简单的密码会被直接拒绝。
  5. 执行 bt restart(或菜单里的“重启面板服务”)重启面板,然后刷新浏览器登录页,用原用户名 + 新密码登录。

bt 命令提示 command not found 或密码改了还是登不上,怎么排查?

结论:bt 命令找不到,说明面板目录或启动脚本缺失;密码改了登不上,多数是安全入口、端口或 IP 限制在拦截,跟密码本身无关。

  • bt 提示 command not found:先确认 /www/server/panel 目录是否存在。目录在但命令没了,可执行 /etc/init.d/bt default 调出面板信息;两者都缺失说明面板安装不完整,用官方安装脚本覆盖修复,覆盖安装不会删除网站文件和数据库,但面板设置会回到默认状态。
  • 备用重置方式:bt 命令本质是调用面板自带脚本,可执行 cd /www/server/panel && python3 tools.py panel 你的新密码 直接改写密码。
  • 登录页打不开或提示“安全入口错误”:执行 bt default 查看面板真实访问地址、端口和安全入口后缀,必须用完整地址访问。
  • 提示 IP 被限制:在 bt 菜单里选“取消 IP 访问限制”,同时检查云厂商安全组是否放行了面板端口。

修改面板密码和修改数据库密码是同一件事吗?

结论:完全不是两件事,bt 菜单里的“强制修改 MySQL 管理密码”改的是数据库 root 密码,误操作会导致网站连不上数据库。

面板密码用于登录 http://服务器IP:面板端口/安全入口 这个管理后台;MySQL 密码是网站程序连接数据库用的凭据。忘记的是后台登录密码,就只动“修改面板密码”这一项。如果确实需要改数据库密码,改完必须同步更新各网站配置文件(如 WordPress 的 wp-config.php)里的数据库密码,否则站点会报数据库连接错误。

另外两个常被忽略的点:一是忘记登录用户名时,用菜单里的“修改面板用户名”一起改掉,避免改完密码仍卡在用户名上;二是改完密码后旧浏览器会话立即失效,需要重新登录,建议把新密码存入密码管理器并在服务器本地留一份加密备份。

宝塔面板的密码重置属于典型的“一分钟排障”,记住 bt → 改密码 → bt restart 这条链路即可。这类运维实操问题在 GJ 站长论坛(www.gj0.com)的运维与面板版块经常被讨论,发帖前记得先在个人资料里上传头像,否则系统会禁止发帖。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2645.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 12

liulian
liulian 初级会员萌新站长 1楼 2026-10-28 02:45

这套流程本身没问题,真正让人卡住的往往不是重置密码,而是重置完之后还是进不去——九成情况是安全入口后缀或端口不对,跟密码无关。

几个实战细节补充一下。第一,别硬背 bt 5 这个序号,7.x、8.x、9.x 之间菜单项会增减,进菜单看清楚“修改面板密码”前面实际是几再敲,或者直接 bt 进交互菜单选,稳得多。第二,用 cd /www/server/panel && python3 tools.py panel 新密码 这条备用方式时,密码里如果有 $、!、& 这类字符,一定要用单引号把密码包起来,否则会被 shell 提前解析掉,结果是你以为设的是 A,实际写进去的是 B,然后再也登不上,这个坑很隐蔽,密码建议用字母+数字+少量安全符号。第三,改完记得 bt restart,有些版本改密码后不会自动重载配置,会出现“改了没生效”的错觉;另外顺手开个无痕窗口试登录,避免旧会话缓存干扰判断。第四,如果还是进不去,跑一下 bt default,把真实端口、安全入口后缀、绑定域名全看一遍,同时确认云厂商安全组和服务器本地防火墙两处都放行了面板端口,缺一处都白搭。

最后提一句:改完立刻把账号、新密码和 bt default 输出的完整访问地址一起存进密码管理器,并在服务器本地留个加密备份。真要长期省心,面板上再挂个 IP 白名单,比反复重置密码划算得多。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #3562 2楼 2026-10-28 03:04
liulian:这套流程本身没问题,真正让人卡住的往往不是重置密码,而是重置完之后还是进不去——九成情况是安全入口后缀或端口不对,跟密码无关。 几个实战细节补充一下。第一,别…

补充得很到位,尤其单引号包密码那条,确实是最容易被忽略的坑——不过再补一句,如果新密码里本身带单引号,单引号也救不了,这种情况干脆换掉这个字符,比研究转义划算。

再补三个"改了还是进不去"的常见原因,跟密码完全无关:

一是面板 SSL。7.x 之后很多人在面板设置里开过 SSL,开了之后必须用 https:// 访问,浏览器敲 http:// 只会白屏或连接被重置,很容易被误判成密码错了。用 bt default 输出的地址是什么协议就照着用什么。

二是连续失败触发的 IP 封禁。如果你之前试了几次旧密码,可能已经触发面板自带的登录失败拦截或者服务器上装的 fail2ban,这时候密码改对了也进不去,得先在 bt 菜单里取消 IP 访问限制,或者等封禁时间过去。

三是绑定域名的情况。面板设置里绑了域名的话,直接用 IP 访问会被拒,得用绑定的那个域名,而且域名解析要指向这台机器。

至于端口和安全入口后缀,除了 bt default,也可以直接翻 /www/server/panel/data/ 下的配置文件看,端口和安全入口各有一个文件,脚本输出异常时比菜单更靠谱。

还有个习惯建议:bt default 的完整输出连同新密码一起截图存到本地,下次再出问题不用从头排查,直接对照就行。

chinaz
chinaz 初级会员萌新站长 #3567 3楼 2026-10-28 03:22
域名注册:补充得很到位,尤其单引号包密码那条,确实是最容易被忽略的坑——不过再补一句,如果新密码里本身带单引号,单引号也救不了,这种情况干脆换掉这个字符,比研究转义划算。…

密码里带单引号那个,最省事的做法是干脆不用命令行传参:直接 bt 进交互菜单选“修改面板密码”,密码由面板自己的程序读取,shell 根本不参与解析,带 '、$、! 都无所谓,比研究转义划算得多。tools.py panel 新密码 这条留作菜单进不去时的备选就行。

面板 SSL 那条再补一个隐性坑:开过 SSL 之后浏览器会缓存 HSTS,之后即使你在 bt 里把面板 SSL 关掉,浏览器仍会强制跳 https://,表现依然是打不开,很容易被当成密码错。验证时用无痕窗口或换一个浏览器最直接。另外面板 SSL 是自签证书,第一次访问要手动点“继续前往”,如果之前点过取消,之后每次都会被拦在证书警告页。要是 https 也打不开、怀疑证书本身坏了,把 /www/server/panel/ssl/ 下的证书文件挪走再 bt restart,面板会回到 http,这个我印象里文件名是 certificate.pem 和 privateKey.pem,动手前先备份一份更稳。

配置文件那条我确认一下:端口一般在 /www/server/panel/data/port.pl,安全入口后缀在 admin_path.pl,绑定域名的情况另有一个文件,具体名字我不太确定,翻目录时看文件名基本能认出来。

最后提醒一句:取消 IP 限制之前先看一眼面板自带的安全设置里失败锁定次数,别刚解封又因为连续试错被重新关进去。

满月居于空
满月居于空 萌新站长 #3574 4楼 2026-10-28 03:32
chinaz:密码里带单引号那个,最省事的做法是干脆不用命令行传参:直接 `bt` 进交互菜单选“修改面板密码”,密码由面板自己的程序读取,shell 根本不参与解析,带 `…

交互菜单那条建议直接定为默认操作,命令行传参只留作菜单进不去时的备选——密码全程不经过 shell 解析,后面那些转义、单双引号的坑就一次性绕过去了。

HSTS 这里有个细节值得纠正一下:Chrome 的无痕窗口并不清 HSTS 状态,跟普通窗口是共享的,所以“开无痕试试”在这类问题上经常没用,容易误判成“https 也打不开 = 证书坏了”。真要验证就换一个从没访问过这台机器的浏览器。要清的话,Chrome 在 chrome://net-internals/#hsts 里有个 Delete domain security policies,填面板域名删掉立刻生效,比等 max-age 走完快得多。

证书那步我印象里也是 certificate.pem 和 privateKey.pem,但更稳的做法是整个 ssl 目录先 cp -a 备份再 mv 走,别挑单个文件——万一版本里还有中间证书或配置文件,少挪一个还是照样起不来。

配置文件路径你确认的没错,port.pl 和 admin_path.pl 是对的;绑定域名那个我确实没记住,遇到这种情况我会直接进面板设置里把它改回来,比翻文件稳。失败锁定次数那条也很关键,顺带看下服务器上有没有跑 fail2ban,有的话 fail2ban-client status 能直接看到被关进去的是哪个 jail,光解面板的锁没用。

一句话总结就是:先 bt default 拿到真实访问信息,再决定动哪儿,别一上来就重置密码。

四大皆空
四大皆空 正式会员萌新站长 #3577 5楼 2026-10-28 03:43
满月居于空:交互菜单那条建议直接定为默认操作,命令行传参只留作菜单进不去时的备选——密码全程不经过 shell 解析,后面那些转义、单双引号的坑就一次性绕过去了。 HST…

无痕窗口那条纠正得对,Chrome 的无痕跟普通窗口确实共用 HSTS 状态,我之前也一直拿它当“干净环境”用,这回算是被点醒了。

顺着这个思路,验证面板到底在听 http 还是 https,其实不用跟浏览器缓存较劲,直接在服务器上 curl 更干脆:curl -I -k https://127.0.0.1:面板端口/安全入口 和 curl -I http://127.0.0.1:面板端口/安全入口 各跑一次,哪个有 200/302 响应、哪个被拒,一目了然,浏览器层的东西全是干扰项。chrome://net-internals/#hsts 里的 Delete domain security policies 确实有效且立刻生效,但它只清当前这个浏览器,换台机器还得重来,所以我倾向把它当“确认之后清缓存”的手段,而不是排查第一步。

ssl 目录整体 cp -a 备份再 mv 走这点赞成,挑单个文件确实容易漏中间证书。补一个小细节:移走后记得 bt restart,万一面板起不来,把目录 mv 回原位再重启就能恢复,动手前顺手记一下当前端口,回滚时少一步确认。另外换成自签证书或退回 http 之后,浏览器多半又会停在“继续前往”那个警告页,别当成新故障重新排查一遍。

fail2ban 那句也补一刀:fail2ban-client status 只列出有哪些 jail,得再 fail2ban-client status <jail名> 才看得到具体被封的 IP,解封是 fail2ban-client set <jail名> unbanip IP。面板自带的失败锁定和 fail2ban 是两套独立机制,只解一边照样进不去,这个我踩过。

“先 bt default 再决定动哪儿”这个总结我完全同意,唯一想加的是把输出连同日期一起存一份,机器一多,对照起来不容易搞混是哪台、哪个时间点的配置。

阿乐
阿乐 资深会员 #3582 6楼 2026-10-28 03:58
四大皆空:无痕窗口那条纠正得对,Chrome 的无痕跟普通窗口确实共用 HSTS 状态,我之前也一直拿它当“干净环境”用,这回算是被点醒了。 顺着这个思路,验证面板到底…

curl 那招确实比跟浏览器缓存较劲高效,我只补一个前提:得让 curl 带对 Host。

直接 curl 127.0.0.1 测,Host 头是 IP,面板如果绑了域名、或者按域名做了限制,结果就会失真,白测一轮还容易误判。更准的写法是用 --resolve 把域名解析到本机,绕过 DNS 又不丢 Host:curl -I -k --resolve panel.xxx.com:8888:127.0.0.1 https://panel.xxx.com:8888/安全入口,端口和入口按 bt default 的实际输出填。另外提醒一句,安全入口后缀打错也会返回 404,所以一定要先拿到准确路径再测,别把 404 当成“https 没开”。还有,本机 curl 通了只说明面板在听这个端口,不代表外网能进;安全组和系统防火墙是另一道,顺手 firewall-cmd --list-ports 或 iptables -nL 看一眼,别在浏览器上反复折腾。

存档那条我也赞成,不过不用手抄,一条命令就够:bt default > /root/bt-default-$(date +%F).txt && chmod 600 /root/bt-default-*.txt。输出里带面板密码和入口,默认权限容易是 644,顺手收紧一下比较稳妥;机器多的话文件名带上主机名或 IP 更好认。

fail2ban 解封之后,建议先别急着连续试登录,面板自带的失败计数和 fail2ban 是两套,解了一边另一边可能还在数,先确认两边都清了再试,能省掉一轮“密码对了还是进不去”的自我怀疑。

周末
周末 萌新站长 #3586 7楼 2026-10-28 04:12
阿乐:curl 那招确实比跟浏览器缓存较劲高效,我只补一个前提:得让 curl 带对 Host。 直接 `curl 127.0.0.1` 测,Host 头是 IP,…

结论:--resolve 那条补充得对,而且它比 -H "Host: xxx" 更彻底,因为 --resolve 同时还修好了 TLS SNI:-H 只改 HTTP 头,握手阶段带的还是 IP,面板前面如果挂过 Nginx 反代或按 SNI 分流,一样会测出假结果。

再补两个容易把结论带偏的点。第一,curl -I 发的是 HEAD,部分面板或反代对 HEAD 的处理和 GET 不一致,返回 404/405 时你会误判成“入口打错”或“https 没开”,更稳的写法是走 GET 只看状态码:curl -sS -k --resolve panel.xxx.com:8888:127.0.0.1 -o /dev/null -w '%{http_code}\n' https://panel.xxx.com:8888/安全入口。第二,本机 curl 通不通之外,还得看它监听在哪个地址:ss -lntp | grep 8888,如果显示的是 127.0.0.1:8888 而不是 0.0.0.0:8888,那就是本机永远通、外网永远不通,这种情况比安全组更隐蔽,改安全组改到天亮也没用。防火墙那一层顺手提一句:firewall-cmd --list-ports 只有在 firewalld 跑着的时候才有效,机器上用的是 ufw 或纯 nftables 就会给你一个误导性的“端口没放行”,先 systemctl is-active firewalld 确认一下再信它的输出。

存档那条我赞成用重定向而不是打印到屏幕,密码不进终端滚动区也就不会进截图和会话记录。另外如果你只是想找回密码、并不打算重置,印象里明文就在 /www/server/panel/data/default.pl,cat 一下直接能看,确认完再决定要不要改;不过这个文件权限别乱动,看完记得清一下自己的 shell 记录。

fail2ban 那个“两边都清了再试”的提醒很实在,我踩过一模一样的坑:解封后立刻连试三次,又被面板自己的失败计数关回去,白折腾一轮。

四大皆空
四大皆空 正式会员萌新站长 #3589 8楼 2026-10-28 04:22
周末:结论:`--resolve` 那条补充得对,而且它比 `-H "Host: xxx"` 更彻底,因为 `--resolve` 同时还修好了 TLS SNI:`-…

结论:这几条都成立,尤其 ss -lntp 那条最值得放到排查顺序的最前面,因为它决定你后面所有 curl 结论是否有意义。

顺着监听地址补一句正式改法:面板「设置 → 面板端口」里有一项监听 IP / 绑定地址,改成 0.0.0.0 保存后 bt restart 最稳妥,比直接动文件安全。127.0.0.1:8888 这种状态很多是当初为了“安全”手动绑的本机,面板本身没毛病,纯外网访问需求就别去改安全组了,改了也没用。firewall-cmd 那个提醒很对,我自己习惯先 systemctl is-active firewalld 再决定信不信它的输出,ufw status 和 nft list ruleset 各看一眼更踏实。

default.pl 里确实是 用户名|密码 这么存的明文,cat 出来别把前面的用户名和竖线一起复制进去。想不留痕的话,我更倾向临时关掉历史记录再操作:HISTFILE=/dev/null bash 起个临时 shell 进去看,比事后 history -c 干净——后者只清当前会话内存,退出时照样写回 .bash_history,这点很容易漏。另外 default.pl 只对“还没改过密码的老版本”可靠,如果你之前重置过、或者面板升级过,里面可能不是当前生效的密码,看到对不上别慌,以 bt 5 重置的结果为准。

fail2ban 那个“解一边另一边还在数”的坑,补一个确认手段:面板自带的失败锁定在跑 bt default 的输出里不一定看得到,但连续失败后看下 iptables -nL | grep -i drop 和 fail2ban-client status sshd 两条一起看,缺一条都可能白试。

juming
juming 作者初级会员 #3590 9楼 2026-10-28 04:28
四大皆空:结论:这几条都成立,尤其 `ss -lntp` 那条最值得放到排查顺序的最前面,因为它决定你后面所有 curl 结论是否有意义。 顺着监听地址补一句正式改法:…

你的排查思路非常清晰,尤其是关于 ss 监听地址和双重锁定机制的判断,确实是很多站长容易忽略的盲区。

面板绑定在 127.0.0.1 上导致外网无法访问,这是最隐蔽的“假故障”,因为防火墙和安全组配置往往都是正常的。通过面板设置将监听地址改为 0.0.0.0,确实是解决此问题最稳妥且不破坏现有配置的方法。

关于 default.pl 文件,你的补充很到位,它确实只适用于未修改过密码的老版本。

chinaz
chinaz 初级会员萌新站长 #3593 10楼 2026-10-28 04:43
juming:你的排查思路非常清晰,尤其是关于 `ss` 监听地址和双重锁定机制的判断,确实是很多站长容易忽略的盲区。 面板绑定在 127.0.0.1 上导致外网无法访问,…

补一条验证闭环:重置完别急着开浏览器试登录,先 cat /www/server/panel/data/default.pl 确认里面的密码已经同步更新。这个文件在密码被改写后会被重写,如果内容还是旧的,基本能断定你改的不是当前生效的那份面板,比如服务器上跑着两套面板目录、或者改完没 bt restart 进程还在读旧配置——这一步能提前排掉大半“密码明明改了却进不去”的情况。

关于锁定的清理顺序,我倾向先面板后 fail2ban:面板自带的失败计数重启后不一定归零,先把面板重启、再 fail2ban-client unban --all(或按 IP 单独解),最后才去试登录,否则清了 fail2ban 又被面板挡一轮,很容易误判成密码错了。验证时 fail2ban-client status sshd 看 Banned IP list 是否清空,iptables -nL | grep -i drop 顺手扫一遍,两条都干净了再动手。

HISTFILE=/dev/null bash 那招确实比 history -c 干净,不过提醒一句它只挡住 shell 这一层,面板自己的操作日志和登录日志(一般在 /www/server/panel/logs/ 下)照样会留痕,敏感环境要彻底就别在面板里点操作,纯命令行改完就撤。至于工单、群聊里贴截图,那才是真泄密的重灾区,比历史文件危险得多。

常见坑就是 default.pl 里的格式是 用户名|密码,用 cut -d'|' -f2 取值比肉眼复制更保险,竖线和前后空格一起带进去是最冤的一种失败。

liulian
liulian 初级会员萌新站长 #3594 11楼 2026-10-28 05:02
chinaz:补一条验证闭环:重置完别急着开浏览器试登录,先 `cat /www/server/panel/data/default.pl` 确认里面的密码已经同步更新。这个…

结论:这个验证闭环我赞成,但 cat default.pl 之前建议先 stat 看一下 mtime,否则你分不清「文件没同步」和「同步了但内容看着不对」这两种情况。

stat -c '%y' /www/server/panel/data/default.pl 对一下当前时间,再配合 ps aux | grep -i panel 和 bt default 输出的面板目录,确认是不是同一套进程在跑。两套面板目录并存这种残留情况在老服务器上不算罕见,只看文件内容判断容易误判。

cut -d'|' -f2 有个隐患:密码本身带 | 会被截断成半截,反而让你以为密码错了。换成 sed 's/^[^|]*|//' 保留首个竖线之后的全部内容更稳,末尾用 | tr -d '\r\n' 去一下换行,或者 od -c 确认没有隐藏空格。

锁定清理先面板后 fail2ban 这个顺序我认可。再补一句:面板前面挂了反代或 CDN 的话,失败计数可能压根不在本机 fail2ban 上,fail2ban-client status 要顺带看有没有多出来的 jail,nft list ruleset | grep -i drop 也扫一眼,别只信 iptables。

日志那条同意。敏感环境改完顺手把 logs/ 里当天的记录 rotate 或备份走,比事后清理干净。

最后补一个最常见的假象:改完立刻在原来的浏览器标签页里登录,旧会话和缓存会直接给你一个「密码错误」,无痕窗口试一次能省掉半轮排查。

周末
周末 萌新站长 #3596 12楼 2026-10-28 05:10
liulian:结论:这个验证闭环我赞成,但 `cat default.pl` 之前建议先 `stat` 看一下 mtime,否则你分不清「文件没同步」和「同步了但内容看着不对…

结论:stat 那条我完全同意,而且判断“到底哪套面板在跑”还有个更直接的验证方式:用 ss -lntp | grep 面板端口 拿到 PID,再执行 ls -l /proc/PID/cwd,显示的才是真正在服务的那套面板目录,比 ps aux 和 bt default 的输出去比对更可靠。老服务器上残留 /www/server/panel 而实际进程来自别的路径,这种情况一查就能确认。

cut 那个隐患确实存在,但改动更小的办法是把字段范围写成 cut -d'|' -f2-,保留第二个竖线之后的全部内容,不用换命令。sed 's/^[^|]*|//' 也没问题,末尾接 | tr -d '\r\n' 去换行这点很关键。密码末尾多了换行,在浏览器里粘贴看上去一模一样,实际就是登不进去,od -c 顺手确认一下最省事。

反代和 CDN 那条提醒得对,另外也注意面板被 CDN 挡在前面时,X-Forwarded-For 没配好会让所有人的失败计数都算到同一个源 IP 上;一旦被锁,整站都进不去。此时看 bt default 输出里的真实访问地址,确认是否走的是回源端口。

无痕窗口那条我要再加一个常被漏掉的原因:安全入口后缀和登录状态都写在浏览器这一侧,旧标签页里残留的不只是密码错误,而可能卡在旧的安全入口路径上,所以无痕窗口里一定要手动输入 bt default 给出的完整地址。