把 RPC 密码直接写进 bitcoin.conf 的人，多半在安全评审时被问过同一个问题：配置文件泄露怎么办。rpcauth 参数就是这条链路上的答案。它的帮助文本写道：Username and HMAC-SHA-256 hashed password for JSON-RPC connections，随后给出字段格式：<USERNAME>:<SALT>$<HASH>，并指出官方附带脚本 share/rpcauth 用于生成这段字符串，客户端连接时仍照常用 rpcuser 与 rpcpassword 配对。
机制上分三段。生成阶段，在自有机器上运行附带脚本，输入用户名与口令，输出一行 用户名:盐$哈希——哈希用盐对口令做 HMAC-SHA-256。配置阶段，把这一行放进配置文件的 rpcauth 项，可多次指定以签发多个账户。认证阶段，请求携带用户名与口令原文，节点按对应用户名的盐重算哈希做比对。明文口令因此不出现在配置文件里；拿到配置文件的攻击者面对的是加盐哈希，仍需离线暴力尝试，弱口令依旧撑不了多久。
源码里它还带一个 SENSITIVE 标记，效果体现在诊断输出：同类被标记的参数在 getsettings 之类的回显里以星号遮罩出现，减少贴日志带出凭据的事故。这条与”配置里没有明文”是两重防护，不要合并叙述成”rpcauth 会自动隐藏一切”。
与默认 cookie 认证的分界值得说清：同机脚本通常走数据目录里的 cookie 文件，节点自行生成、随重启轮换，无需 rpcauth；rpcauth 的价值出现在需要长期、命名、可分权的凭据时——给监控系统、备份服务、第二台运维机各发一个账号，出事时精确吊销单个账户而非全员改密。两者可共存。再强调一条常被记反的依赖：-rpcbind 想监听非本机地址，必须同时给 -rpcallowip 放行来源，否则帮助文本说了它会被忽略；rpcauth 管认证，地址白名单是另一道门。
运维红线三条。生成凭据永远在自己机器上跑脚本，抄示例里的盐哈希等于全网共用密码。含 rpcauth 行的配置备份，保密等级应视同半把钥匙；若被提交进仓库或贴上网，视同口令泄露，走删号重发流程，而不是”反正有哈希”兜底。多账户场景给每个服务最小权限时间窗，定期轮换从源头消灭”祖传密码”。
适用判断一句话：单机自用、只有本地脚本调用时，cookie 最省心；一旦有第二台机器、第二个服务、第二个人要碰 RPC，rpcauth 的分账户与哈希存储价值立刻显现。文本与脚本位置可能随版本微调，以你所用版本的 -help 与 share 目录实际内容为准。
给一个可照做的最小流程收束全文。第一步，确认威胁模型：RPC 是否可能被本机之外的进程访问、配置文件会不会进版本库、是否有第三方服务需要长期接入。第二步，生成凭据：在自己的机器上进入发行包对应目录运行官方 rpcauth 脚本，得到形如 监控用户:十六进制盐$十六进制哈希 的行，把口令原文记进密码管理器而不是终端历史。第三步，写入配置并重启，用一个被授权账户和一个错误口令各发一次 RPC，确认前者通过、后者被拒。第四步，检查 getsettings 一类的诊断输出里敏感项是否被遮罩，把含配置文件的备份纳入同等保密。第五步，写一张吊销预案：哪个账户能做什么、出事先撤谁。
安全上再强调一句边界哲学：rpcauth 提升的是”配置泄露后的抗性”与”多身份可审计性”，它不提供传输加密以外的魔法，也不替你把防火墙、fail2ban、端口收敛这些老生常谈做掉。把 RPC 想成一把开在服务器上的门，认证只是门上的锁，锁再好，门不该朝公网开就不该开。所有文本与默认行为以所用版本的 -help 与源码为准，脚本位置在不同打包渠道可能略有差异，找不到时先查发行包的 share 目录。
风险提示：RPC 凭据泄露或远程暴露等同交出节点控制权，公网开放 RPC 前请完整评估网络边界与认证组合。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。