postgresql - sirve - psql: FATAL: la autenticación de pares falló para el usuario "dev"

postgresql vs mysql (8)

cuando creo un nuevo usuario, pero no puede iniciar sesión en la base de datos.
Lo hago así:

postgres@Aspire:/home/XXX$ createuser dev Shall the new role be a superuser? (y/n) n Shall the new role be allowed to create databases? (y/n) y Shall the new role be allowed to create more new roles? (y/n) y

luego crea una base de datos:

postgres@Aspire:/home/XXX$ createdb -O dev test_development

después de eso, intento psql -U dev -W test_development para iniciar sesión, pero obtengo el error:

psql: FATAL: Peer authentication failed for user "dev"

Traté de resolver el problema pero fallé.

Cuando especifica:

psql -U user

se conecta a través de UNIX Socket, que de forma predeterminada utiliza peer autenticación de peer , a menos que se especifique en pg_hba.conf en pg_hba.conf contrario.

Puedes especificar:

host database user 127.0.0.1/32 md5 host database user ::1/128 md5

para obtener una conexión TCP / IP en la interfaz loopback (tanto IPv4 como IPv6) para la database y el user especificados.

Después de los cambios, debe reiniciar Postgres o volver a cargar su configuración. Reinicie que debería funcionar en las modernas distribuciones basadas en RHEL / Debian:

service postgresql restart

Reload debería funcionar de la siguiente manera:

pg_ctl reload

pero el comando puede diferir dependiendo de la configuración de PATH - puede que tenga que especificar la ruta absoluta, que puede ser diferente, dependiendo de la forma en que se instaló el postgres.

Entonces puedes usar:

psql -h localhost -U user -d database

para iniciar sesión con ese user a la database especificada sobre TCP / IP. md5 significa contraseña encriptada, mientras que también puede especificar password para password de texto sin formato durante la autorización. Estas 2 opciones no deberían ser una gran cuestión siempre que el servidor de base de datos solo sea accesible localmente, sin acceso a la red.

Nota importante: orden de definición en pg_hba.conf : las reglas se leen de arriba a abajo, como iptables, por lo que probablemente desee agregar reglas propuestas por encima de la regla:

host all all 127.0.0.1/32 ident

En mi caso, estaba usando un puerto diferente. El valor predeterminado es 5432. Estaba usando 5433. Esto funcionó para mí:

$ psql -f update_table.sql -d db_name -U db_user_name -h 127.0.0.1 -p 5433

Esto funciona para mí cuando me encuentro con esto:

sudo -u username psql

La autenticación de pares significa que postgres le pregunta al sistema operativo por su nombre de usuario y lo usa para la autenticación. Para iniciar sesión como usuario "dev" utilizando la autenticación de pares en postgres, también debe ser el usuario "dev" en el sistema operativo.

Puede encontrar detalles sobre los métodos de autenticación en la documentación de Postgresql .

Sugerencia: Si ya no funciona ningún método de autenticación, desconecte el servidor de la red y use el método "trust" para "localhost" (y compruebe que su servidor no es accesible a través de la red mientras el método "trust" está habilitado).

La solución más fácil:

CREATE USER dev WITH PASSWORD ''dev''; CREATE DATABASE test_development; GRANT ALL PRIVILEGES ON DATABASE test_development to dev; ALTER ROLE dev CREATEROLE CREATEDB;

Si bien la respuesta de @flaviodesousa funcionaría, también hace obligatorio que todos los usuarios (todos los demás) ingresen una contraseña.

En algún momento tiene sentido mantener la autenticación entre iguales para todos los demás, pero haga una excepción para un usuario del servicio. En ese caso, le gustaría agregar una línea al pg_hba.conf que se ve así:

local all some_batch_user md5

Le recomendaría que agregue esta línea justo debajo de la línea de encabezado comentada:

# TYPE DATABASE USER ADDRESS METHOD local all some_batch_user md5

Deberá reiniciar PostgreSQL usando

sudo service postgresql restart

Si está utilizando 9.3, su pg_hba.conf probablemente sería:

/etc/postgresql/9.3/main/pg_hba.conf

Su conexión ha fallado porque, de forma predeterminada, psql conecta a través de sockets UNIX mediante peer autenticación de peer , eso requiere que el usuario actual de UNIX tenga el mismo nombre de usuario que psql . Por lo tanto, deberá crear el usuario dev UNIX y luego iniciar sesión como dev o usar sudo -u dev psql test_development para acceder a la base de datos (y psql no debería pedir una contraseña).

Si no puede o no quiere crear el usuario de UNIX, como si solo desea conectarse a su base de datos para consultas ad hoc , forzando una conexión de socket usando psql --host=localhost --dbname=test_development --username=dev ( como lo señala @meyerson answer) resolverá su problema inmediato.

Pero si tiene la intención de forzar la autenticación de contraseña en sockets Unix en lugar del método peer, intente cambiar la siguiente línea pg_hba.conf *:

# TYPE DATABASE USER ADDRESS METHOD local all all peer

# TYPE DATABASE USER ADDRESS METHOD local all all md5

peer significa que confiará en la identidad (autenticidad) del usuario de UNIX. Entonces no pides una contraseña.
md5 significa que siempre pedirá una contraseña y la validará después de hash con MD5 .

Por supuesto, también puede crear reglas más específicas para una base de datos o usuario específico, con algunos usuarios que tienen peer y otros que requieren contraseñas.

Después de cambiar pg_hba.conf si se está ejecutando PostgreSQL, tendrá que volver a leer la configuración mediante la recarga ( pg_ctl reload ) o el reinicio ( sudo service postgresql restart ).

^{* El archivo pg_hba.conf probablemente estará en /etc/postgresql/9.x/main/pg_hba.conf}

Editado: Comentarios de @Chloe, @JavierEH, @Jonas Eicher, @fccoelho, @Joanis, @Uphill_What comentarios incorporados en la respuesta.

Tratar:

psql user_name -h 127.0.0.1 -d db_name

dónde

-h es el nombre de host / IP del servidor local, lo que evita los sockets de dominio de Unix
-d es el nombre de la base de datos para conectarse a

Esto es evaluado como una conexión de "red" por Postgresql en lugar de una conexión de socket de dominio Unix, por lo tanto no se evalúa como una conexión "local" como se puede ver en pg_hba.conf :

local all all peer