PostgreSQL数据库空密码登录是一个极其危险的安全隐患，它意味着任何知道数据库地址和端口的人，都可能无需任何身份验证就直接访问你的数据。要彻底禁止它，核心方法是修改数据库的认证配置文件"pg_hba.conf"，将所有认证方法从"trust"或"peer"改为"md5"、"scram-sha-256"等密码认证方式，并为所有数据库用户设置强密码。
理解PostgreSQL的认证流程：pg_hba.conf是关键
PostgreSQL的客户端认证完全由"pg_hba.conf"（Host-Based Authentication）文件控制。这个文件决定了哪些主机、哪些数据库、哪些用户可以通过何种方式进行连接。每一行就是一条认证规则，PostgreSQL会从上到下匹配第一条符合的连接请求规则并执行其认证方法。其中，“空密码登录”的罪魁祸首通常就是认证方法被设置为"trust"。"trust"意味着完全信任，无需任何密码。另一个可能导致类似情况的方法是"peer"，它仅适用于本地系统用户同名登录，但在特定配置下也可能绕过密码检查。
定位并修改pg_hba.conf配置文件
首先，你需要找到"pg_hba.conf"文件的位置。它通常位于PostgreSQL的数据目录（data directory）下。你可以通过连接到数据库并执行以下SQL命令来找到数据目录：
SHOW data_directory;
或者，在服务器命令行中，使用"psql"工具执行。找到文件后，使用文本编辑器（如vim或nano）以管理员权限打开它。你会看到类似下面的内容：
# TYPE DATABASE USER ADDRESS METHOD local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust host all all 0.0.0.0/0 trust
上面是一个典型的不安全配置示例。"TYPE"为"local"代表本地Unix域套接字连接，"host"代表TCP/IP连接。"ADDRESS"为"0.0.0.0/0"代表允许来自任何IP地址的连接。最关键的是"METHOD"（方法）一列，这里全是"trust"，这就是允许空密码登录的原因。
将危险认证方法改为密码认证
你必须将所有"trust"方法（针对需要密码登录的用户和主机）修改为需要密码的认证方法。推荐使用"scram-sha-256"，这是PostgreSQL目前最安全的密码认证方式。如果老版本客户端不支持，可以暂时使用"md5"作为过渡。修改后的配置示例如下：
# TYPE DATABASE USER ADDRESS METHOD local all all scram-sha-256 host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 host all all 192.168.1.0/24 scram-sha-256 # 仅允许内网段 host all all 0.0.0.0/0 reject # 明确拒绝其他所有IP
这个配置做了几件关键事：
1. 将所有本地和指定网络（127.0.0.1， ::1， 192.168.1.0/24）的连接方法改为了"scram-sha-256"，要求密码；
2. 最后一条规则，对于来自其他任何地址（0.0.0.0/0）的连接，直接使用"reject"方法拒绝，这是最安全的做法。如果你需要从公网访问，应将"0.0.0.0/0"这条规则的"METHOD"也改为"scram-sha-256"，并务必配合强密码和防火墙策略。
为数据库用户设置强密码
仅仅修改认证方法还不够，你必须确保每个数据库用户都有一个强密码。如果用户密码为空，即使认证方法改为"md5"或"scram-sha-256"，攻击者仍可能尝试暴力破解或利用其他漏洞。使用PostgreSQL命令行工具"psql"或图形化管理工具为用户设置密码：
-- 以postgres超级用户身份连接后，修改某个用户的密码 ALTER USER your_username WITH PASSWORD 'YourStrongPassword!2024';
请将"'YourStrongPassword!2024'"替换为高强度的密码，建议长度超过12位，包含大小写字母、数字和特殊符号。切勿使用默认密码或简单密码。
应用配置更改并重启服务
修改并保存"pg_hba.conf"文件后，PostgreSQL需要重新加载配置才能生效。通常，发送一个SIGHUP信号给主进程或重启服务即可。你可以在命令行执行：
# 重新加载配置（无需重启，不会中断现有连接） pg_ctl reload -D /your/data/directory # 或者使用系统服务命令 sudo systemctl reload postgresql # 适用于systemd系统 sudo service postgresql reload # 适用于SysVinit系统
如果修改了监听地址（"listen_addresses" in "postgresql.conf"）或某些极端情况，可能需要完全重启服务：
sudo systemctl restart postgresql
重启后，立即尝试用空密码连接数据库，验证是否已被禁止。可以使用"psql"命令测试："psql -h your_host -U your_user -d your_db"，系统应提示输入密码。
进阶安全加固：超越禁止空密码
禁止空密码只是数据库安全的第一步。一个资深的运维人员会采取更多纵深防御措施：
1. 最小权限原则： 在"pg_hba.conf"中，不要对所有数据库（"all"）和所有用户（"all"）使用宽松规则。应该为不同的应用和用户创建单独的规则，限制其只能访问特定的数据库。例如：
host myapp_db myapp_user 192.168.1.100/32 scram-sha-256
2. 更改默认端口： 将默认的5432端口改为其他端口，可以减少自动化扫描工具的攻击。
3. 网络层防火墙： 使用服务器防火墙（如iptables, firewalld）或云安全组，严格限制可以访问PostgreSQL端口（默认5432）的源IP地址，只允许可信的应用程序服务器或管理终端IP。
4. 定期审计与监控： 启用PostgreSQL的日志功能（"log_connections"和"log_disconnections"），记录所有连接和登录尝试，定期检查日志中是否有异常或失败的登录请求，这通常是攻击的前兆。
5. 使用SSL/TLS加密连接： 在"postgresql.conf"中启用"ssl = on"，并在"pg_hba.conf"中对远程连接使用"hostssl"替代"host"，强制所有网络传输加密，防止密码和数据在传输中被窃听。
常见问题与故障排除
问题：修改后所有用户都无法登录了。 这通常是因为"pg_hba.conf"中规则的顺序或范围有误。记住，第一条匹配的规则生效。如果你为某个IP设置了"reject"，而允许的规则在其之后，那么连接就会被拒绝。请仔细检查规则顺序和CIDR地址格式。
问题：本地脚本或服务连接失败。 本地连接（如cron作业、本机应用）如果之前依赖"trust"，现在需要密码。解决方法有：
1. 使用密码文件（".pgpass"）安全地存储密码；
2. 对于特定的本地系统用户到数据库用户的映射，可以考虑使用"peer"或"ident"方法，但这需要系统用户名和数据库用户名一致，且仅适用于本地连接。
问题：如何验证当前生效的认证规则？ 可以连接到数据库后查看"pg_hba_file_rules"系统视图，它会清晰地展示当前加载的规则：
SELECT * FROM pg_hba_file_rules ORDER BY line_number;
总之，禁止PostgreSQL空密码登录不是一个可选项，而是安全运维的强制性底线。它通过将"pg_hba.conf"中的"trust"认证方法改为"scram-sha-256"或"md5"等密码验证方式，并结合为所有用户设置强密码来实现。完成此操作后，务必进行全面的连接测试，并以此为基础，构建包括网络隔离、权限细分、连接加密和日志监控在内的多层防御体系，才能确保你的数据库在面对外部威胁时固若金汤。
