Udostępnij za pośrednictwem

Uwierzytelnianie hasłem nie powiodło się dla użytkownika <user-name>

Ten artykuł ułatwia rozwiązanie problemu, który może wystąpić podczas nawiązywania połączenia z usługą Azure Database for PostgreSQL — serwer elastyczny.

Objawy

Podczas próby nawiązania połączenia z usługą Azure Database for PostgreSQL — serwer elastyczny może wystąpić następujący komunikat o błędzie:

psql: error: connection to server at "<server-name.postgres.database.azure.com>" (x.x.x.x), port 5432 failed: FATAL: password authentication failed for user "user-name" (błąd 5432: uwierzytelnianie hasła nie powiodło się dla użytkownika "<user-name>"

Ten błąd wskazuje, że hasło podane dla użytkownika <user-name> jest niepoprawne.

Po początkowym błędzie uwierzytelniania haseł może zostać wyświetlony kolejny komunikat o błędzie wskazujący, że klient próbuje ponownie nawiązać połączenie z serwerem, tym razem bez szyfrowania SSL. Błąd jest spowodowany tym, że konfiguracja serwera pg_hba.conf nie zezwala na niezaszyfrowane połączenia.

połączenie z serwerem pod adresem "<nazwa-serwera.postgres.database.azure.com>" (x.x.x.x.x), port 5432 nie powiodło się: BŁĄD KRYTYCZNY: brak wpisu pg_hba.conf dla hosta "y.y.y.y", użytkownik "<user-name>", baza danych "postgres", brak szyfrowania

W przypadku korzystania z klienta obsługującego libpq protokół SSL, takiego jak narzędzia, takie jak psql, pg_dumplub pgbench, jest to standardowe zachowanie, aby spróbować nawiązać połączenie raz przy użyciu protokołu SSL i raz bez. Przyczyną tego podejścia jest to, że serwer może mieć różne pg_hba reguły dotyczące połączeń SSL i innych niż SSL. Komunikat o połączonym błędzie wyświetlany w tym scenariuszu wygląda następująco:

psql: error: connection to server at "<server-name.postgres.database.azure.com" (x.x.x.x.x),port 5432 failed: password authentication failed for user "<user-name>" connection to server at "server-name.postgres.database.azure.com>>" (x.x.x.x), port 5432 failed: FATAL: no pg_hba.conf entry for host "<y.y.y.y", użytkownik "<user-name>", baza danych "postgres", brak szyfrowania

Aby uniknąć tej podwójnej próby i określić żądany tryb SSL, użyj sslmode opcji połączenia w konfiguracji klienta. Jeśli na przykład używasz libpq zmiennych w powłoce powłoki bash, możesz ustawić tryb SSL przy użyciu następującego polecenia:

export PGSSLMODE=require

Przyczyna

Błąd napotkany podczas nawiązywania połączenia z usługą Azure Database for PostgreSQL — serwer elastyczny wynika głównie z problemów związanych z uwierzytelnianiem haseł:

  • Nieprawidłowe hasło Uwierzytelnianie hasła nie powiodło się w przypadku błędu użytkownika <user-name> , gdy hasło użytkownika jest nieprawidłowe. Może się to zdarzyć z powodu błędnie wtypowanego hasła, niedawnej zmiany hasła, która nie została zaktualizowana w ustawieniach połączenia lub innych podobnych problemów.

  • Użytkownik lub rola utworzona bez hasła Inna możliwa przyczyna tego błędu polega na utworzeniu użytkownika lub roli w usłudze PostgreSQL bez określania hasła. Wykonywanie poleceń, takich jak CREATE USER <user-name> lub CREATE ROLE <role-name> bez towarzyszącej instrukcji hasła, powoduje, że użytkownik lub rola nie mają ustawionego hasła. Próba nawiązania połączenia z tego rodzaju użytkownikami lub rolami bez ustawienia hasła doprowadzi do niepowodzenia uwierzytelniania z powodu błędu uwierzytelniania hasła.

  • Potencjalne naruszenie zabezpieczeń Jeśli niepowodzenie uwierzytelniania jest nieoczekiwane, szczególnie jeśli zarejestrowano wiele nieudanych prób, może to wskazywać na potencjalne naruszenie zabezpieczeń. Próby nieautoryzowanego dostępu mogą powodować takie błędy.

Rozwiązanie

Jeśli występuje błąd "Uwierzytelnianie haseł nie powiodło się dla użytkownika <user-name>", wykonaj następujące kroki, aby rozwiązać ten problem.

  • Spróbuj nawiązać połączenie za pomocą innego narzędzia

    Jeśli błąd pochodzi z aplikacji, spróbuj nawiązać połączenie z bazą danych przy użyciu innego narzędzia, takiego jak psql lub pgAdmin, z tą samą nazwą użytkownika i hasłem. Ten krok pomaga określić, czy problem jest specyficzny dla klienta, czy szerszy problem z uwierzytelnianiem. Należy pamiętać o wszelkich odpowiednich regułach zapory, które mogą mieć wpływ na łączność. Aby uzyskać instrukcje dotyczące nawiązywania połączenia przy użyciu różnych narzędzi, zapoznaj się z blokiem "Połącz" w witrynie Azure Portal.

  • Zmienianie hasła

    Jeśli po wypróbowaniu innego narzędzia nadal występują problemy z uwierzytelnianiem haseł, rozważ zmianę hasła dla użytkownika. W przypadku użytkownika administratora możesz zmienić hasło bezpośrednio w witrynie Azure Portal zgodnie z opisem w tym linku. W przypadku innych użytkowników lub użytkownika administratora w pewnych warunkach możesz zmienić hasło z wiersza polecenia. Upewnij się, że zalogowano się do bazy danych jako użytkownik z atrybutem CREATEROLE i opcją ADMIN w jego roli. Polecenie zmiany hasła to:

    ALTER USER <user-name> PASSWORD '<new-password>';

  • Ustawianie hasła dla użytkownika lub roli utworzonej bez jednego

    Jeśli przyczyną błędu jest utworzenie użytkownika lub roli bez hasła, zaloguj się do wystąpienia bazy danych PostgreSQL i ustaw hasło roli. W przypadku ról utworzonych bez LOGIN uprawnień upewnij się, że przyznaj to uprawnienie wraz z ustawieniem hasła:

    ALTER ROLE <role-name> LOGIN;
ALTER ROLE <role-name> PASSWORD '<new-password>';

  • Jeśli podejrzewasz potencjalne naruszenie zabezpieczeń

    Jeśli podejrzewasz, że potencjalne naruszenie zabezpieczeń powoduje nieautoryzowany dostęp do usługi Azure Database for PostgreSQL — serwer elastyczny, wykonaj następujące kroki, aby rozwiązać ten problem:

    1. Włącz przechwytywanie dzienników , jeśli przechwytywanie dzienników nie jest jeszcze włączone, skonfiguruj go teraz. Rejestrowanie klucza przechwytywania pod kątem działań bazy danych i przechwytywanie wszelkich dziwnych wzorców dostępu. Istnieje kilka sposobów, takich jak usługa Azure Monitor Log Analytics i dzienniki serwera, które ułatwiają przechowywanie i analizowanie dzienników zdarzeń bazy danych.

    2. Identyfikowanie adresu IP osoby atakującej

      • Przejrzyj dzienniki, aby znaleźć adres IP, z którego są wykonywane nieautoryzowane próby dostępu. Jeśli osoba atakująca korzysta z narzędzia opartego libpqna systemie, adres IP zostanie wyświetlony we wpisie dziennika skojarzonym z nieudaną próbą połączenia:

        połączenie z serwerem pod adresem "<nazwa-serwera.postgres.database.azure.com>" (x.x.x.x.x), port 5432 nie powiodło się: BŁĄD KRYTYCZNY: brak wpisu pg_hba.conf dla hosta "y.y.y.y", użytkownik "<user-name>", baza danych "postgres", brak szyfrowania

        W tym przykładzie jest to adres IP, y.y.y.y z którego osoba atakująca próbuje nawiązać połączenie.

      • Zmodyfikuj opcję log_line_prefix Aby ulepszyć rejestrowanie i ułatwić rozwiązywanie problemów, należy zmodyfikować log_line_prefix parametr w konfiguracji bazy danych PostgreSQL, aby uwzględnić adres IP hosta zdalnego. Aby zarejestrować nazwę hosta zdalnego lub adres IP, dodaj kod ucieczki %h do pliku log_line_prefix.

        Możesz na przykład zmienić format log_line_prefix na następujący w celu kompleksowego rejestrowania:

        log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h '

        Ten format obejmuje:

        • %t dla znacznika czasu zdarzenia
        • %p identyfikator procesu
        • [%l-1] dla numeru wiersza sesji
        • %d jako nazwę bazy danych
        • %u jako nazwę użytkownika
        • %a jako nazwę aplikacji
        • %h dla adresu IP klienta

        Korzystając z tego prefiksu wiersza dziennika, można śledzić czas, identyfikator procesu, użytkownika, aplikację i adres IP klienta skojarzony z każdym wpisem dziennika, zapewniając cenny kontekst dla każdego zdarzenia w dzienniku serwera.

    3. Blokuj adres IP osoby atakującej, aby uzyskać dostęp do dzienników, aby wykryć wszelkie podejrzane adresy IP, które nadal pojawiają się w nieautoryzowanych próbach dostępu. Po znalezieniu tych adresów IP natychmiast zablokuj je w ustawieniach zapory. Spowoduje to odcięcie dostępu i zapobiegnie wszelkim nieautoryzowanym próbom. Ponadto przejrzyj reguły zapory, aby upewnić się, że nie są zbyt permissywne. Nadmiernie szerokie reguły mogą uwidaczniać bazę danych w przypadku potencjalnych ataków. Ogranicz dostęp tylko do znanych i niezbędnych zakresów adresów IP.

Wykonując poniższe kroki, należy rozwiązać problemy z uwierzytelnianiem i pomyślnie nawiązać połączenie z usługą Azure Database for PostgreSQL — serwer elastyczny. Jeśli nadal występują problemy po wykonaniu podanych wskazówek, nie wahaj się zgłosić biletu pomocy technicznej.