FTP账号密码能不能在服务器上直接“看到”，取决于它存在哪一端服务端配置文件里基本是哈希或加密串，客户端保存的往往只是Base64这类可逆编码，真正的明文通常只在设置密码的那一刻出现过。
很多人接手一台服务器,第一反应是翻配置文件找明文密码，翻完发现全是乱码一样的字符串，于是以为文件坏了，其实不是坏了，是设计上就不该让你读到明文，下面按“先分清哪一端、再动手查”的顺序，把能查的、查不到的、查到后怎么处理讲清楚。
先分清你查的是哪一端的密码
FTP这套东西至少有两端在存凭据,混在一起查会白费功夫。
服务端存的是校验值，不是密码本身
服务端要做的是“验证你输入的密码对不对”，不需要知道原密码，所以Linux系统用户走/etc/shadow，虚拟用户走PAM数据库或独立密码文件，存的基本都是crypt哈希，哈希是单向的，能比对、不能反推。
客户端存的多是可逆编码
你在FileZilla、WinSCP里勾了“保存密码”，它得能自动登录，就必须把密码还原出来，所以客户端这边用的是可逆编码或可逆加密，安全性靠的是本机账户权限，不是算法强度。
还有一种容易被忽略：面板和数据库里的虚拟用户
宝塔、云帮手这类面板，FTP账号存在面板自己的数据库里；有些企业用MySQL做虚拟用户后端，这类位置的密码同样是哈希，但账号清单看得见，改密码比找密码更现实。
Linux服务器上FTP账号密码存放位置在哪
这是最常被搜的问题,按服务端软件分，位置差别不小。
系统用户型FTP：看/etc/passwd和/etc/shadow
如果FTP登录用的就是系统账户,账号名能在/etc/passwd里看到，密码字段在/etc/shadow里，普通用户读不了，需要root。
sudo grep ftp /etc/passwd sudo grep 用户名 /etc/shadow
看到的是$6$开头的SHA-512哈希，或者、表示该账户没有可用密码。这里永远不会有明文。
vsftpd的虚拟用户库
vsftpd是Linux上最常见的FTP服务端之一,虚拟用户配置通常在：
- 主配置：
/etc/vsftpd/vsftpd.conf - PAM配置：
/etc/pam.d/vsftpd - 用户库：
/etc/vsftpd/virtual_users.db（由db_load从文本生成）
PAM配置里会有一行类似db=/etc/vsftpd/virtual_users，指向的就是哈希库，文本源文件virtual_users.txt里存的也是哈希，不是明文。
pure-ftpd和ProFTPD
pure-ftpd的密码文件一般是/etc/pure-ftpd/pureftpd.passwd，可以用pure-pw show 用户名查看账户信息，但密码字段仍是哈希。
ProFTPD看/etc/proftpd/proftpd.conf里的AuthUserFile指向，常见是/etc/proftpd/ftpd.passwd，同样是哈希。
一张表看清各服务端的情况
| 服务端软件 | 密码存储位置 | 存储形态 | 能否直接读出明文 |
|---|---|---|---|
| vsftpd虚拟用户 | /etc/vsftpd/virtual_users.db |
哈希 | 否 |
| pure-ftpd | /etc/pure-ftpd/pureftpd.passwd |
哈希 | 否 |
| ProFTPD | AuthUserFile指向文件 |
哈希 | 否 |
| FileZilla Server | FileZilla Server.xml |
加盐哈希 | 否 |
| 宝塔面板 | 面板数据库ftp表 | 哈希 | 否 |
| 系统用户 | /etc/shadow |
哈希 | 否 |
规律很清楚：服务端没有任何一处给你留明文后门。
vsftpd虚拟用户密码怎么找回
这是高频场景：老运维离职，FTP账号还在，密码没人知道，正确思路不是“找回”，是“重置”。
先确认PAM认证走的是哪个库
打开/etc/pam.d/vsftpd，找到pam_userdb.so那一行，后面的db=路径就是实际生效的用户库，别改错文件。
用db_load重建虚拟用户表
步骤是固定的：
- 备份原库：
cp /etc/vsftpd/virtual_users.db /root/virtual_users.db.bak - 生成新哈希：
openssl passwd -1 新密码 - 编辑文本源文件,把对应用户名后面的哈希替换掉
- 重新生成库：
db_load -T -t hash -f virtual_users.txt virtual_users.db - 重启服务：
systemctl restart vsftpd
如果只想新增一个账号,同样走这套流程，注意文件权限保持600，属主是root。
pure-ftpd更简单
直接一条命令：
pure-pw passwd 用户名 -f /etc/pure-ftpd/pureftpd.passwd pure-pw mkdb
能重置就别纠结还原，这是运维里的常规做法。
FTP客户端保存的密码怎么导出
服务器上查不到,很多时候答案其实在你自己的电脑里之前连过的人，客户端替他记着。
FileZilla：Base64不是加密
FileZilla的站点管理器密码存在用户目录下的sitemanager.xml，字段形如<Pass encoding="base64">xxxxx</Pass>，它只是Base64编码，解码就是明文：
echo 'xxxxx' | base64 -d
快速连接历史记录在recentservers.xml，格式一样，这个设计业内讨论多年，本质是把安全性交给了操作系统账户权限。
WinSCP和FlashFXP：可逆加密
WinSCP的会话信息在注册表HKCU\Software\Martin Prikryl\WinSCP 2\Sessions下，密码用主机名和用户名派生密钥加密，不能直接算出来，最稳妥的方式是在WinSCP里打开站点，用自带的导出功能，FlashFXP的Sites.dat也是类似思路。
系统凭据管理器
Windows的“控制面板→凭据管理器”、macOS的“钥匙串访问”，都可能存着FTP登录信息，搜一下主机名或域名，能看到保存的条目。
前提要说清楚：这些操作只适用于你自己的设备、你自己有权限的账号。 动别人的电脑导密码，性质完全不同。
简米云服务器上怎么查看FTP账号密码有什么不同
云服务器本身不改变FTP的存储逻辑,变的只是入口和周边。
- 登录方式：通过控制台的VNC或SSH密钥登录，拿到的还是同一套Linux文件系统。
- 宝塔面板用户：FTP账号在面板的“FTP”菜单里能看到用户名，密码同样以哈希存在面板数据库中，面板只提供“改密码”，不提供“看密码”。
- 快照和镜像：如果误删了配置文件，可以从快照恢复出旧文件，但恢复出来的仍是哈希。
- 安全组：查密码之前先确认21端口和被动模式端口段是通的，不然查到密码也连不上。
FTP密码找回要多少钱
这个问题得分情况。
- 自己动手：成本为零，需要的是服务器root权限和十几分钟时间，按上面的重置流程走一遍即可。
- 找服务商或第三方：一般是按工时或按次计费，价格取决于服务器数量、是否有面板、是否需要顺带做权限梳理，企业环境下更常见的做法是签一份运维审计服务，把账号盘点、密码轮换、权限回收打包处理，而不是单次“找密码”。
- 所谓“密码破解服务”：对哈希做字典和规则碰撞，成功率取决于密码强度。弱口令几分钟，强口令可能永远跑不出来。 这类操作必须在书面授权范围内进行，否则触碰的是合规红线，按照《网络安全法》对网络运营者账号管理和日志留存的要求，企业内部做凭据审计本身是正当需求，但前提是授权链条完整。
几个容易踩的坑
- 把
/etc/shadow里的当成密码，其实那表示账户被锁定、没有可用密码。 - 改了
virtual_users.txt却忘了重新db_load，重启服务后密码还是旧的。 - 只改服务端不改客户端,客户端还在用旧密码自动重试，日志里一堆530。
- 用在线Base64解码网站处理真实密码,等于把密码发给第三方。
Q&A：FTP账号密码查看常见问题
为什么在服务器配置里查看FTP账号密码，只看到一串字符？
因为服务端只需要校验,不需要还原，你看到的是哈希值，比对逻辑是“把输入的密码用同样算法算一遍，看结果是否一致”，想拿到可用密码，正确做法是重置，不是解码。
没有root权限还能查看FTP账号密码吗？
基本不能。/etc/shadow和多数FTP密码文件默认只有root可读，面板数据库同理，普通账户能看到的通常只有用户名和连接配置，密码字段被权限挡住，这也是权限分级的意义所在。
公司交接时FTP密码对不上，排查顺序是什么？
先确认连的是哪台服务器、哪个端口；再看服务端用的是系统用户还是虚拟用户，对应到具体密码文件；然后确认客户端保存的是不是旧密码；最后直接重置密码并同步给使用方，行业共识认为，交接场景下重置比重试更省时间，也更容易留下可追溯的操作记录。
核心就一句话：服务端查的是账号和哈希，客户端查的是可逆编码，真想拿到能用的密码，重置永远比还原靠谱。 把这套位置表和重置流程记下来，下次再遇到“FTP密码在哪”的问题，十分钟内就能定位到该动哪个文件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/796142.html
