Freigeben über

Authentifizierung des Kennworts für Benutzer*in <user-name> fehlgeschlagen

Dieser Artikel hilft Ihnen bei der Lösung eines Problems, das beim Herstellen einer Verbindung mit Azure Database for PostgreSQL – Flexibler Server auftreten kann.

Problembeschreibung

Beim Versuch, eine Verbindung mit Azure Database for PostgreSQL – Flexibler Server herzustellen, tritt möglicherweise die folgende Fehlermeldung auf:

PSQL: Fehler: Verbindung zum Server „<server-name>.postgres.database.azure.com“ (x.x.x.x), Port 5432 fehlgeschlagen: SCHWERWIEGEND: Kennwortauthentifizierung für Benutzer*in „<user-name>“ fehlgeschlagen

Dieser Fehler gibt an, dass das für Benutzer*in <user-name> verwendete Kennwort falsch ist.

Nach dem anfänglichen Kennwort-Authentifizierungsfehler wird möglicherweise eine weitere Fehlermeldung angezeigt, die besagt, dass der Client versucht, sich erneut mit dem Server zu verbinden, dieses Mal ohne SSL-Verschlüsselung. Der Fehler ist hier auf die Konfiguration des pg_hba.conf Servers zurückzuführen, die keine unverschlüsselten Verbindungen zulässt.

Verbindung zum Server „<server-name>.postgres.database.azure.com“ (x.x.x.x), Port 5432 fehlgeschlagen: SCHWERWIEGEND: kein pg_hba.conf-Eintrag für Host „y.y.y.y“, Benutzer*in „<user-name>“, Datenbank „postgres“, keine Verschlüsselung

Wenn Sie einen libpq-Client verwenden, der SSL unterstützt, z. B. Tools wie psql, pg_dump oder pgbench, ist es üblich, zu versuchen, eine Verbindung einmal mit und einmal ohne SSL herzustellen. Dieser Ansatz wird verwendet, da der Server unterschiedliche pg_hba-Regeln für SSL- und nicht-SSL-Verbindungen aufweisen kann. Die kombinierte Fehlermeldung, die Sie in diesem Szenario erhalten, sieht wie folgt aus:

PSQL: Fehler: Verbindung zum Server „<server-name>.postgres.database.azure.com“ (x.x.x.x), Port 5432 fehlgeschlagen: SCHWERWIEGEND: Kennwortauthentifizierung für Benutzer*in „<user-name>“ für die Verbindung zum Server „<server-name>.postgres.database.azure.com“ (x.x.x.x), Port 5432 fehlgeschlagen: SCHWERWIEGEND: kein pg_hba.conf-Eintrag für host „y.y.y.y“, Benutzer*in „<user-name>“, Datenbank „postgres“, keine Verschlüsselung

Um diesen doppelten Versuch zu vermeiden und den gewünschten SSL-Modus anzugeben, verwenden Sie die sslmode-Verbindungsoption in Ihrer Clientkonfiguration. Wenn Sie beispielsweise libpq-Variablen in der Bash-Shell verwenden, können Sie den SSL-Modus mit dem folgenden Befehl festlegen:

export PGSSLMODE=require

Ursache

Der Fehler, der bei der Verbindung zu Azure Database for PostgreSQL – Flexibler Server auftritt, ist in erster Linie auf Probleme im Zusammenhang mit der Kennwortauthentifizierung zurückzuführen:

  • Falsches Kennwort Der Fehler „Kennwortauthentifizierung für Benutzer*in <user-name> fehlgeschlagen“ tritt auf, wenn das Kennwort für den bzw. die Benutzer*in falsch ist. Dies kann durch ein falsch eingegebenes Kennwort, eine kürzlich vorgenommene Kennwortänderung, die in den Verbindungseinstellungen noch nicht aktualisiert wurde, oder andere ähnliche Probleme verursacht werden.

  • Ohne Kennwort erstellte*r Benutzer*in oder Rolle Eine andere mögliche Ursache für diesen Fehler ist das Erstellen eines Benutzers bzw. einer Benutzerin oder einer Rolle in PostgreSQL ohne Angabe eines Kennworts. Das Ausführen von Befehlen wie CREATE USER <user-name> oder CREATE ROLE <role-name> ohne zugehörige Kennwortausweisung führt zu einem Benutzer bzw. einer Benutzerin oder einer Rolle, für die kein Kennwort festgelegt ist. Der Versuch, eine Verbindung mit dieser Art von Benutzern oder Rollen herzustellen, ohne ein Kennwort festzulegen, führt zu einem Authentifizierungsfehler mit der Fehlermeldung „Kennwortauthentifizierung fehlgeschlagen“.

  • Potenzielle Sicherheitsverletzung Wenn der Authentifizierungsfehler unerwartet ist, insbesondere, wenn mehrere fehlgeschlagene Versuche aufgezeichnet werden, könnte dies auf eine potenzielle Sicherheitsverletzung hinweisen. Solche Fehler können durch nicht autorisierte Zugriffsversuche ausgelöst werden.

Lösung

Wenn der Fehler „Kennwortauthentifizierung für Benutzer*in <user-name> fehlgeschlagen“ auftritt, führen Sie die folgenden Schritte aus, um das Problem zu beheben.

  • Versuchen Sie, eine Verbindung mit einem anderen Tool herzustellen

    Wenn der Fehler aus einer Anwendung kommt, versuchen Sie, mithilfe eines anderen Tools wie psql oder pgAdmin mit demselben Benutzernamen und Kennwort eine Verbindung mit der Datenbank herzustellen. Dieser Schritt hilft bei der Ermittlung, ob es sich um ein clientspezifisches Problem oder ein größeres Authentifizierungsproblem handelt. Denken Sie an alle relevanten Firewallregeln, die sich auf die Konnektivität auswirken können. Anweisungen dafür, wie Sie eine Verbindung mit verschiedenen Tools herstellen, finden Sie im Azure-Portal auf dem Blatt „Verbinden“.

  • Ändern Sie das Kennwort

    Wenn Sie auch mit einem anderen Tool Probleme mit der Kennwortauthentifizierung haben, sollten Sie das Kennwort des Benutzers bzw. der Benutzerin ändern. Für Administratorbenutzer*innen können Sie das Kennwort direkt im Azure-Portal ändern, wie in diesem Link beschrieben. Für andere Benutzer*innen oder unter bestimmten Umständen auch für Administratorbenutzer*innen können Sie das Kennwort über die Befehlszeile ändern. Stellen Sie sicher, dass Sie als Benutzer*in mit dem Attribut CREATEROLE und der Option ADMIN bei der Datenbank angemeldet sind. Der Befehl zum Ändern des Kennworts lautet:

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

  • Festlegen des Kennworts für Benutzer*innen oder Rollen, die ohne Kennwort erstellt wurden

    Wenn die Ursache des Fehlers die Erstellung eines Benutzers bzw. einer Benutzerin oder einer Rolle ohne Kennwort ist, melden Sie sich bei Ihrer PostgreSQL-Instanz an und legen Sie das Kennwort für die Rolle fest. Achten Sie bei Rollen, die ohne die Berechtigung LOGIN erstellt wurden darauf, diese Berechtigung beim Festlegen des Kennworts zu gewähren:

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

  • Wenn Sie eine potenziellen Sicherheitsverletzung vermuten

    Wenn Sie den Verdacht haben, dass eine potenzielle Sicherheitsverletzung einen nicht autorisierten Zugriff auf Ihre Azure Database for PostgreSQL – Flexibler Server verursacht, befolgen Sie diese Schritte, um das Problem zu beheben:

    1. Protokollerfassung aktivieren Wenn die Protokollerfassung noch nicht aktiviert ist, aktivieren Sie sie jetzt. Die Erfassung von Protokollen ist wichtig, um die Datenbankaktivitäten im Auge zu behalten und merkwürdige Zugriffsmuster zu erkennen. Es gibt mehrere Möglichkeiten, dies zu tun, einschließlich Azure Monitor Log Analytics und Serverprotokolle, die bei der Speicherung und Analyse von Datenbankereignisprotokollen helfen.

    2. Identifizieren der IP-Adresse des Angreifers bzw. der Angreiferin

      • Überprüfen Sie die Protokolle, um die IP-Adresse zu finden, von der die nicht autorisierten Zugriffsversuche vorgenommen stammen. Wenn der Angreifer bzw. die Angreiferin ein libpq-basiertes Tool verwendet, wird die IP-Adresse im Protokolleintrag angezeigt, der dem fehlgeschlagenen Verbindungsversuch zugeordnet ist:

        Verbindung zum Server „<server-name>.postgres.database.azure.com“ (x.x.x.x), Port 5432 fehlgeschlagen: SCHWERWIEGEND: kein pg_hba.conf-Eintrag für Host „y.y.y.y“, Benutzer*in „<user-name>“, Datenbank „postgres“, keine Verschlüsselung

        In diesem Beispiel ist y.y.y.y die IP-Adresse, von der aus der Angreifer bzw. die Angreiferin versucht, eine Verbindung herzustellen.

      • Ändern Sie log_line_prefix Um die Protokollierung zu verbessern und die Problembehandlung zu vereinfachen, sollten Sie den Parameter log_line_prefix in Ihrer PostgreSQL-Konfiguration so ändern, dass er die IP-Adresse des Remotehosts einschließt. Um den Remotehostnamen oder die IP-Adresse zu protokollieren, fügen Sie den Escapecode %h zu ihrem log_line_prefix hinzu.

        Sie können ihre log_line_prefix beispielsweise in das folgende Format ändern, um umfassende Protokollierung zu erhalten:

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

        Dieses Format umfasst:

        • %t für den Zeitstempel des Ereignisses
        • %p für die Prozess-ID
        • [%l-1] für die Sitzungszeilennummer
        • %d für den Datenbanknamen
        • %u für den Benutzernamen
        • %a für den Anwendungsnamen
        • %h für die IP-Adresse des Clients

        Mithilfe dieses Präfixes für die Protokollzeile können Sie die Zeit, die Prozess-ID, den bzw. die Benutzer*in, die Anwendung und die Client-IP-Adresse für jeden Protokolleintrag nachverfolgen, wodurch Sie wertvolle Informationen zu jedem Ereignis im Serverprotokoll erhalten.

    3. Blockieren der IP-Adresse des Angreifers bzw. der Angreiferin Schauen Sie sich die Protokolle genau an, um verdächtige IP-Adressen ausfindig zu machen, die immer wieder bei unbefugten Zugriffsversuchen auftauchen. Sobald Sie diese IPs gefunden haben, blockieren Sie sie sofort in Ihren Firewalleinstellungen. Dies unterbindet ihren Zugriff und verhindert weitere unautorisierte Versuche. Überprüfen Sie außerdem Ihre Firewall-Regeln, um sicherzustellen, dass sie nicht zu freizügig sind. Zu weit gefasste Regeln können Ihre Datenbank potenziellen Angriffen aussetzen. Beschränken Sie den Zugriff auf bekannte und notwendige IP-Bereiche.

Wenn Sie diese Schritte befolgen, sollten Sie in der Lage sein, die Authentifizierungsprobleme zu beheben und erfolgreich eine Verbindung mit Ihrer Azure Database for PostgreSQL – Flexibler Server herzustellen. Wenn Sie weiterhin Probleme haben, nachdem Sie die bereitgestellten Anleitungen befolgen, zögern Sie nicht, ein Supportticket einzureichen.