最近，一些PostgreSQL用户报告说，他们在切换到PostgreSQL 14后出现了连接失败。
”为什么会得到错误FATAL:用户密码认证失败在新的服务器上?已经成为最有趣的的问题。
至少在一个案例中，应用程序的信息是这样的，这让人有点惊讶:
FATAL:连接数据库失败:连接到服务器在“localhost”(::1)，端口5432失败:fe_sendauth:没有提供密码
出现这些错误的原因是新版本的PostgreSQL将密码加密的默认值更改为SCRAM身份验证。尽管最后一个似乎与SCRAM没有直接关系，哦，是的，一些安装后脚本失败了，它正在寻找“md5”。
在PostgreSQL中，SCRAM身份验证并不是什么新鲜事。它从PostgreSQL 10开始就存在了，但从来没有影响到DBA的生活，因为它从来都不是默认的。这是一个通过显式更改默认设置来选择加入的功能。那些选择加入的人通常理解并有意这样做，而且从来没有听说过会引起任何问题。PostgreSQL社区多年来一直不愿意将其作为主要方法，因为许多客户端/应用程序库还没有为SCRAM身份验证做好准备。
但是这种情况在PostgreSQL 14中正在改变。随着PostgreSQL 9.6不再支持，情况正在发生变化。现在，我们期望所有旧的客户端库都得到升级，而SCRAM身份验证正在成为主要的密码身份验证方法。但是，那些完全不知道的人总有一天会受到惊喜的欢迎。这篇文章的目的是让那些还没有意识到的人快速意识到，并解决一些常见的问题。
什么是SCRAM身份验证?
简单来说，就是数据库客户机和服务器相互证明并说服对方知道密码不需要交换密码或密码散列。是的，可以通过执行加盐的挑战和响应，sdn - sha -256来实现RFC 7677。这种存储、通信和验证密码的方式使得破解密码变得非常困难。
这种方法更能抵抗:
- 字典攻击
- 重播攻击
- 甜面包散列
总的来说，破解基于密码的身份验证变得非常困难。
随着时间的推移，什么发生了变化?
通道绑定
身份验证只是安全通信的一部分。身份验证之后，中间的恶意服务器可能会接管并欺骗客户端连接。PostgreSQL 11引入了支持通道绑定的sgram - sha -256- plus。这是为了确保没有流氓服务器充当真实服务器或进行中间人攻击。
从PostgreSQL 13开始，客户端可以请求甚至坚持通道绑定。
例如:
|
1
2
3.
|
psql
-U
postgres
-h
c76pri
channel_binding=更喜欢
或
psql
-U
postgres
-h
c76pri
channel_binding=需要
|
通道绑定在SSL/TLS上工作，因此必须配置SSL/TLS才能使通道绑定工作。
设置密码加密
的md5是PostgreSQL 10之前唯一可用的密码加密选项，因此PostgreSQL允许设置指示“密码加密是必需的”，默认为md5。
|
1
2
3.
|
高达PG13
postgres = #
集
password_encryption
来
在；
集
|
由于同样的原因，上述说法实际上与:
|
1
2
|
postgres = #
集
password_encryption
来
MD5；
集
|
我们甚至可以用“true”，“1”，“yes”来代替“on”作为等价的值。
但现在我们有多种加密方法，“开启”并不能真正传达我们真正想要的。所以从PostgreSQL 14开始，系统期望我们指定加密方法。
|
1
2
|
postgres = #
集
password_encryption
来
“安全- sha - 256”；
集
|
|
1
2
|
postgres = #
集
password_encryption
来
md5的；
集
|
任何尝试使用“on”/“true”，“yes”将被拒绝并报错。
|
1
2
3.
4
|
- - -从
PG14
postgres = #
集
password_encryption
来
“上”；
错误:无效的
价值
为
参数
“password_encryption”：
“上”
提示:可用
值：
md5，急停-沙-256.
|
因此，请检查您的脚本，并确保它们没有“启用”加密的旧方法。
一些常见问题
- 我的逻辑备份和恢复会受到影响吗?
逻辑备份和恢复PostgreSQL全局变量(pg_dumpall)不会影响SCRAM认证，恢复后使用相同的密码即可。事实上，回想一下SCRAM身份验证对更改的适应性更强，这将是一件有趣的事情。例如，如果我们重命名一个USER，旧的MD5密码将不再起作用，因为PostgreSQL生成MD5的方式也使用用户名。
postgres=# ALTER USER jobin1 RENAME TO job;
注意:由于角色重命名导致MD5密码被清除
改变的作用
注意提示pg_authid中的密码哈希值将被清除，因为旧的密码哈希值不再有效。但是SCRAM身份验证不会出现这种情况，因为我们可以在不影响密码的情况下重命名用户。
postgres=# ALTER USER jobbin RENAME TO jobin1;
改变的作用 - 现有/旧的加密方法(md5)是一个很大的漏洞。风险很大吗?
这种担忧主要来自于“MD5”这个名字，对于现代硬件来说，这个名字太愚蠢了。PostgreSQL使用md5的不同之处在于不仅仅是密码的哈希值，它还考虑了用户名。此外，它是在使用服务器提供的随机盐准备散列后通过网络进行通信的。实际上，所传达的内容将不同于密码散列，因此它不太容易受到攻击。但容易受到字典攻击和泄露用户名密码哈希问题。 - 新的scram身份验证广告的身份验证复杂吗?我的连接请求会花更多的时间吗?
有线协议SCRAM非常高效，并且不会导致连接时间下降。此外，与服务器端连接管理的其他开销相比，由SCRAM创建的开销可以忽略不计 - 是否强制使用PostgreSQL 14中的SCRAM身份验证，并强制所有用户帐户切换到它?
当然不是，只改变了默认值。旧的方法md5仍然是一个有效的方法，如果访问PostgreSQL环境受到防火墙/hba规则的限制，使用md5的风险已经比较小了。 - 为什么当我切换到PostgreSQL 14时，我得到“:FATAL: password authentication failed for user”错误?
最可能的原因是pg_hba.conf条目。如果我们指定“md5”作为身份验证方法，PostgreSQL也将允许SCRAM身份验证。但反过来是行不通的。当你创建PostgreSQL 14环境时，它很可能会使用“scran -sha-256”作为身份验证方法。In some of the PostgreSQL packages, the installation script automatically does it for you In case the authentication works from the PostgreSQL client tools and not from the application, please检查驱动程序版本检查升级范围 - 为什么我得到其他类型的身份验证错误?
最可能的原因是安装后脚本。在许多组织中，使用DevOps工具(Ansible/Chef)甚至shell脚本来进行安装后定制是一种常规做法。其中许多人会做一系列的事情，包括设置password_encryption TO ON;甚至可以使用sed对pg_hba.conf进行修改，如果它试图修改一个已经不存在的条目，那么预计会失败。
我为什么要在乎，该怎么做
从自动化/部署脚本、工具、应用程序连接和连接池开始的任何东西都可能被破坏。将此更改推迟到PostgreSQL 14的主要理由之一是，最古老的支持版本(9.6)很快就会停止支持。因此，现在是检查您的环境的正确时机，看看这些环境中是否有旧的PostgreSQL库(9.6或更老版本)，并有升级计划，因为旧版本的PostgreSQL库无法处理SCRAM协商。
总之，制定一个好的迁移计划是有帮助的，即使它不是紧急的。
-
- 检查环境和应用程序驱动程序，看看它们是否仍在使用旧版本的PostgreSQL客户端库，并在需要的地方升级它们。
请参阅:https://wiki.postgresql.org/wiki/List_of_drivers
鼓励/推动客户端库的升级 - 如果现有环境正在使用md5，则鼓励用户切换到SCRAM身份验证。
记住，在pg_hba.conf中提到的认证方法“md5”也将继续适用于PostgreSQL 14中的SCRAM和md5认证。 - 利用一切机会测试并将自动化、连接池和其他基础设施迁移到SCRAM身份验证。
- 检查环境和应用程序驱动程序，看看它们是否仍在使用旧版本的PostgreSQL客户端库，并在需要的地方升级它们。
通过改变默认的身份验证，PostgreSQL社区为未来指明了一个明确的方向。
雷竞技下载官网Percona发行版为PostgreSQL提供了来自开源社区的最好和最关键的企业组件，在一个发行版中，设计和测试了一起工作。
