这事儿我经手过不少次，咱们一步步把它说透：

一、差异产生的核心原因 #

你执行sudo -u postgres psql postgres时，本质是先通过sudo切换到系统用户postgres，再以该用户身份连接本地PostgreSQL实例。PostgreSQL对这种本地套接字连接（而非TCP/IP连接）采用了特殊的认证规则，而其他登录方式（比如远程TCP连接、用其他系统用户直接登录）匹配的是不同的认证策略，所以需要密码。

关键在于PostgreSQL的认证规则文件pg_hba.conf——它会根据连接类型（本地/远程）、数据库、用户、来源IP等维度，决定采用哪种认证方式。你当前的配置里，针对系统用户postgres的本地连接，大概率用的是peer或trust认证，跳过了密码校验；而其他连接方式（比如TCP连接、非postgres系统用户的本地连接）则配置了md5或scram-sha-256这类需要密码的认证方式。

另外你提到postgres用户不在sudoers里，这没问题——是你当前的登录用户有sudo权限，所以能切换到postgres用户，和postgres本身有没有sudo权限没关系。

二、免密逻辑的具体配置 #

要确认配置，先找到pg_hba.conf的位置：

sudo -u postgres psql -c 'show hba_file;'

打开这个文件，你会看到类似这样的规则（通常在文件顶部）：

# 针对本地套接字的postgres用户连接
local   all             postgres                                peer

或者可能是更宽松的trust：

local   all             postgres                                trust

• peer认证：PostgreSQL会检查当前系统用户名是否和要登录的PostgreSQL用户名完全一致，一致就允许免密登录——这就是你切换到postgres系统用户后能直接进psql的原因。
• trust认证：直接允许所有符合条件的连接，无需任何校验（安全性较低，一般不推荐）。

修改完pg_hba.conf后，需要重载PostgreSQL配置生效：

sudo systemctl reload postgresql

三、为其他用户配置相同的免密方式 #

当然可以，分两种常见场景：

场景1：系统用户与PostgreSQL用户名一致 #

比如你想让系统用户dev免密登录PostgreSQL的dev用户，只需在pg_hba.conf里添加一行：

local   all             dev                                     peer

重载配置后，执行sudo -u dev psql dev就能免密登录了。

场景2：系统用户与PostgreSQL用户名不一致 #

比如想让系统用户admin免密登录PostgreSQL的postgres用户，就需要用到身份映射：

1. 在pg_hba.conf里修改或添加规则，指定映射文件：

local   all             postgres                                ident map=postgres-admin-map

2. 找到pg_ident.conf的位置（用sudo -u postgres psql -c 'show ident_file;'查看），添加映射规则：

postgres-admin-map  admin    postgres

这里的格式是[映射名称] [系统用户名] [PostgreSQL用户名]。
3. 重载PostgreSQL配置，之后执行sudo -u admin psql postgres就能免密登录了。

⚠️ 注意：trust认证虽然能快速实现免密，但会让所有符合条件的连接直接进入数据库，安全性极低，生产环境尽量用peer或ident映射。

内容的提问来源于stack exchange，提问作者BurningKrome