L'utilisateur PostgreSQL ne peut pas se connecter au serveur après avoir changé de mot de passe

J'ai rencontré cela avec 4 rôles que j'ai créés:
Après avoir changé le mot de passe d'un utilisateur dans pgAdmin III en utilisant l'interface graphique (1), cet utilisateur ne peut plus se connecter.
pgAdmin III affiche un message d'erreur:

An error has occurred:

Error connecting to the server: FATAL:  password authentication failed for user "sam"
FATAL:  password authentication failed for user "sam"

Mon système: Postgresql 9.2 sur Ubuntu 12.04

Est-ce qu'il y a un moyen de réparer ceci?

(1): connectez-vous avec le compte postgres, faites un clic droit sur l'utilisateur dans les rôles de connexion, allez dans l'onglet «Définition» et entrez le mot de passe

Il est possible que vous soyez mordu par ce bogue PgAdmin ( changelog ):

2012-11-28 AV 1.16.1 Les contrôles du sélecteur de date retournent un horodatage complet par défaut, ce qui peut entraîner des modifications de date par inadvertance sur les travaux et les dates de validité des rôles. Ignorez la partie temps.

Ce bug a été vu pour fixer des dates d'expiration de mot de passe dans le passé, comme 1/1/1970. Dans ce cas, le message d'erreur lors de la tentative de connexion n'est pas différent de celui d'un mot de passe incorrect.

Vous pouvez vérifier ces dates d'expiration avec:

SELECT usename,valuntil FROM pg_user;

et s'ils se trompent, réinitialisez-les avec:

ALTER USER username VALID UNTIL 'infinity';

et mettez à niveau pgAdmin.

La chose simple à faire est de se connecter avec psql ou pgAdmin et

ALTER USER sam WITH PASSWORD 'new_password';

Maintenant, si vous ne pouvez pas vous connecter avec un compte superutilisateur, vous pouvez récupérer en modifiant les paramètres pg_hba.conf pour cet utilisateur et recharger la configuration (parfois, je trouve que cela nécessite de redémarrer le serveur, mais je ne sais pas pourquoi).

Ce que vous pouvez faire est d'ajouter une ligne qui vous permet de vous connecter en utilisant la méthode ident (peer in 9.2) (si vous pouvez utiliser un compte système local du même nom que l'utilisateur) pour les connexions locales pour l'utilisateur, ou (si ce n'est pas possible) réglé sur "confiance" (très temporairement!). Si vous utilisez la confiance, reculez dès que possible, car cela signifie "faites confiance à l'utilisateur qui est celui qu'il réclame!" et par conséquent, ce paramètre est dangereux de laisser activé en dehors des besoins de récupération immédiate.

Une fois connecté, vous pouvez réinitialiser le mot de passe ci-dessus.

Pour la variante Windows - J'ai également rencontré ce méchant bogue à cause de pgAdmin pour mon installation Windows x64 de la version 9.2. Cela a laissé ma production paralysée.

Dans le dossier C:\Program Files\PostgreSQL\9.2\dataou C:\Program Files (x86)\PostgreSQL\9.**x**\data, vous trouverez le fichier texte pg_hba.conf .

Trouvez les lignes suivantes:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

et changez la MÉTHODE md5 en "confiance" comme ceci:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

A partir du Windows>Runtype "services.msc" et [entrée] recherchez la bonne instance PostgreSQL et redémarrez-la.

Votre sécurité DB est maintenant complètement ouverte! Tenez compte de l'avertissement pour le renvoyer à md5 après avoir modifié l'heure d'expiration du mot de passe utilisateur pour indiquer l'année 2099 pour tous les utilisateurs concernés.

Si vous ne l'avez pas déjà essayé, consultez votre fichier pg_hba.conf. Il sera nommé quelque chose comme /var/lib/pgsql/9.3/data/pg_hba.conf (Fedora 20); vous devrez peut-être utiliser «find / -name pg_hba.conf» pour le localiser.

En bas du fichier, changez les valeurs de 'METHOD' en 'trust' pour les tests locaux (voir la documentation de postgres pour des informations complètes). Redémarrez la machine pour vous assurer que tout démarre correctement et que les nouveaux paramètres sont lus.

Espérons que cela guérira vos malheurs. Il a résolu mes problèmes sur Fedora 20 avec PostgreSQL 9.3.

MISE À JOUR 2016-10-14:

Sur Ubuntu, le nom de fichier requis est /etc/postgresql/9.5/main/pg_hba.conf. Pour les tests locaux uniquement , modifiez-le pour qu'il ressemble à ceci:

...
#
# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
# local   all             all                                     peer
  local   all             all                                     trust
# IPv4 local connections:
# host    all             all             127.0.0.1/32            md5
  host    all             all             127.0.0.1/32            trust

Les deux lignes avec la méthode "trust" sont nouvelles. Ils vous permettent de vous connecter sans nom d'utilisateur / mot de passe.

Une fois terminé, vous devrez redémarrer le serveur via:

sudo systemctl restart postgresql 

Je viens d'avoir ce même problème et il s'est avéré que j'avais plusieurs utilisateurs avec le même nom (cas différents). Une fois que j'ai fusionné la propriété et en ai retiré une, c'était au moins clair. Selon la méthode de connexion, le cas n'était pas nécessairement transféré pour authentification.