Selbstgehostet – Passwort zurücksetzen ohne SMTP-Konfiguration

Fragen
1

Hallo!

Ich betreibe n8n auf GCP CloudRun mit PostgreSQL. Wir haben ein paar Instanzen für unterschiedliche Anforderungen im Einsatz.
Auf einer der Instanzen hat sich der erste Benutzer registriert und ist daher Eigentümer geworden. Er ist der einzige Eigentümer/Admin auf dieser Instanz. Er hat sein Passwort vergessen und kann es nicht zurücksetzen, weil wir SMTP nicht konfiguriert haben.

Was ist der einfachste Weg, ein Passwort zurückzusetzen?

Ist es sicher, die Rolle direkt in der Datenbank auf global:admin zu setzen und dann einen neuen Eigentümer zu registrieren, der einen Passwort-Reset-Link generieren kann?

2

Hey @rgrzesk, während du auf eine Antwort wartest, findest du hier ein paar hilfreiche Dinge:

[details=“Empfohlene Ressourcen”]

Automatisch zu deiner Frage zugeordnet.

Docs:

Forum:

3

Hi @rgrzesk

Hier ist eine Möglichkeit, Benutzer zurückzusetzen.
Dies löscht keine anderen Daten wie Workflows oder Anmeldedaten. Nur Benutzer.

4

Hallo @rgrzesk

Da du bereits im GCP-Ökosystem arbeitest, kannst du die Cloud Shell verwenden, um dich direkt mit deiner Cloud SQL-Instanz zu verbinden und das Passwort-Hash manuell zu aktualisieren. Dies umgeht die Notwendigkeit, n8n lokal auszuführen oder Verschlüsselungsschlüssel zu verwalten.

  1. Öffne die GCP Cloud Shell von deiner Google Cloud Console.
  2. Verbinde dich mit deiner Cloud SQL-Instanz mit dem folgenden Befehl:
gcloud sql connect [YOUR_INSTANCE_NAME] --user=postgres
  1. Generiere einen neuen bcrypt-Hash. Da n8n bcrypt verwendet, kannst du nicht einfach ein Klartext-Passwort eingeben. Du kannst diese Python-Einzeiler in deiner Cloud Shell verwenden, um einen Hash für dein gewünschtes Passwort zu generieren (z. B. NewPassword123!):
python3 -c 'import bcrypt; print(bcrypt.hashpw(b"NewPassword123!", bcrypt.gensalt()).decode())'

Kopiere die resultierende Zeichenkette (sie beginnt mit $2b$...).

  1. Führe das SQL-Update aus. Führe in der PostgreSQL-Eingabeaufforderung den folgenden Befehl aus. Hinweis: user ist ein reserviertes Wort in PostgreSQL und muss in doppelte Anführungszeichen gesetzt werden.
UPDATE "user" 
SET "password" = '[PASTE_YOUR_HASH_HERE]' 
WHERE "email" = '[OWNER_EMAIL_ADDRESS]';
  1. Verifiziere und beende:
SELECT email FROM "user" WHERE email = '[OWNER_EMAIL_ADDRESS]';
\q
  1. Melde dich bei n8n mit dem neuen Passwort an.
5

Hallo @rgrzesk Willkommen!

Dein global:admin-Plan funktioniert nicht — der Setup-Assistent ist am settings-Schlüssel userManagement.isInstanceOwnerSetUp = true gated, nicht daran, ob eine global:owner-Zeile existiert. Das Herabstufen des Eigentümers hinterlässt dich also ohne Eigentümer und immer noch ohne /setup. (global:admin ist auch eine Enterprise-lizenzierte Rolle.)

Da du Postgres nutzt, schreib einfach den bcrypt-Hash dieses Benutzers um. Eine Spalte, nichts sonst angefasst, kein Redeploy:

1. Hash generieren (n8n nutzt bcryptjs, cost 10):

docker run --rm node:20-alpine sh -c \
  "npm i bcryptjs --silent --prefix /tmp >/dev/null 2>&1 && \
   node -e \"console.log(require('/tmp/node_modules/bcryptjs').hashSync('YourNewPass1',10))\""

Nutz ein Passwort, das n8ns Regeln erfüllt (8–64 Zeichen, 1 Ziffer, 1 Großbuchstabe), oder du kannst es später in der UI nicht ändern.

2. Verbinden und aktualisieren:

UPDATE "user"
SET password = '$2b$10$...your hash...'
WHERE email = 'owner@yourdomain.com';

Zwei Dinge, die Leute stolpern lassen: user ist in Postgres ein reserviertes Wort und muss mit doppelten Anführungszeichen versehen werden, und der Hash muss in einfachen Anführungszeichen in deinem Shell-Befehl stehen, sonst expandiert bash $2b/$10 und schreibt Unsinn.

Hatte das Konto MFA aktiviert, dann auch SET "mfaEnabled" = false, "mfaSecret" = NULL, "mfaRecoveryCodes" = NULL.

3. Meld dich von einem Inkognito-Fenster an — n8n leitet einen Teil des Auth-JWT vom Passwort-Hash ab, also werden alte Sessions ungültig und ein stales Cookie wirft dich raus. Kein Container-Restart nötig.

Vermeide n8n user-management:reset hier: Du kannst nicht in Cloud Run mit docker exec gehen, und es löscht alle Benutzerkonten und versetzt die Instanz zurück in den Setup-Assistenten. Es lohnt sich, danach SMTP-Umgebungsvariablen auf deinen Cloud-Run-Services zu setzen, damit das nicht über die ganze Fleet hinweg wieder vorkommt.

6

Hier verwenden wir self-hosted auf Railway. Um das Problem zu beheben, habe ich Variablen direkt in die Dienste Primary und Worker aufgenommen. Danach habe ich das Deployment durchgeführt und das Problem war gelöst.

image

image
image587×167 1.57 KB

7

Ich habe versucht (auf meiner Testinstanz), einen anderen Benutzer von global:owner zu global:admin zu ändern, und es hat funktioniert. Nach dem Betreten der Instanz habe ich den /setup-Bildschirm erneut gesehen. Der Trick funktioniert also gut.
Die Frage ist – ist das sicher? Werden diese Rollen nicht auch irgendwo anders gespeichert/verwendet?

8

Das ist das, was ich als solide und langfristige Lösung planen möchte :slight_smile: Im Moment versuche ich nur, die Instanz schnell ohne zusätzliche Deployments wiederherzustellen.

9

Du hast recht, mein Fehler — das neuere n8n entscheidet, ob /setup angezeigt wird, basierend darauf, ob eine global:owner-Zeile existiert, nicht auf dem Settings-Schlüssel, den ich zitiert habe. Danke, dass du es getestet hast.

Zur Sicherheit: Es gibt drei verschiedene role-Spalten, und sie sind separate Dinge. user.role ist die Instance-Rolle (diejenige, die du geändert hast). project_relation.role und shared_workflow/shared_credentials.role regeln Projektmitgliedschaft und Ressourceneigentümerschaft — und diese sind an projectId, nicht userId gebunden. Also berührt nichts von dem, was du getan hast, wer welchen Workflow oder welche Credentials besitzt. Dieser Teil ist in Ordnung.

Das eine, das ich ändern würde: Verwende global:member statt global:admin. Admin ist ein Pro/Enterprise-Kontotyp, also auf Community hast du einen Benutzer in einer Rolle geparkt, die die Instance nicht lizenzieren kann — und die UI neigt dazu, nicht lizenzierte Rollen auszugrauen, sodass du es möglicherweise nicht ohne einen weiteren DB-Schreibzugriff zurückändern kannst. Member gibt dir den gleichen Setup-Screen ohne diese Probleme.

Also: DB-Snapshot → setze alten Owner auf global:member → registriere einen wegwerfbaren Owner → Einstellungen → Benutzer → kopiere den Password-Reset-Link für das alte Konto (funktioniert prima ohne SMTP) → zurücksetzen → Rollen zurücksetzen → temporären Benutzer löschen. Lasse nicht zwei global:owner-Zeilen gleichzeitig stehen.

Auf jeden Fall lohnt es sich, N8N_EMAIL_MODE=smtp auf alle deine Cloud Run-Services zu bekommen — mit einem Owner pro Instance kommt das wieder vor.

10

Hi @rgrzesk
Ab n8n 2.17.0 kann der Instance-Owner aus Umgebungsvariablen bereitgestellt werden, was das Passwort zurückgesetzt, ohne die Datenbank überhaupt anzutasten. Stellen Sie diese auf dem Cloud Run-Dienst ein und verwenden Sie die E-Mail des vorhandenen Eigentümers:

N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true
N8N_INSTANCE_OWNER_EMAIL=owner@yourdomain.com
N8N_INSTANCE_OWNER_FIRST_NAME=Firstname
N8N_INSTANCE_OWNER_LAST_NAME=Lastname
N8N_INSTANCE_OWNER_PASSWORD_HASH=<bcrypt hash>

n8n wendet diese bei jedem Start erneut auf das vorhandene Owner-Konto an, sodass die Revision mit bereits geändertem Passwort hochkommt. Während das Flag aktiv ist, ist dieser Benutzer in der UI schreibgeschützt und API-Schreibvorgänge für ihn werden abgelehnt. Sobald Sie angemeldet sind, setzen Sie N8N_INSTANCE_OWNER_MANAGED_BY_ENV=false, die angewendeten Werte bleiben bestehen und die UI wird wieder freigeschaltet.
Es kostet eine Revision, aber keine Rollenänderungen und nichts zum Rückgängigmachen in der DB danach, was sich über den Rest Ihrer Instanzen skaliert.