it seems to work in the check routine of the New Credential dialog.
However: When I use the credentials in an SSH-Node I get the same error again.
When I go back to the credential the content of the Private Key field has changed to something like __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
The same occurs when I enter the key as expression, close the credential window and reopen it again immediatly. Then the check of the key fails as well.
How can I even store SSH-Keys in n8n without getting them destroyed?
Bei der Betrachtung deiner bereitgestellten JSON versuchst du, Schlüsseldateien manuell innerhalb eines Execute a command-Knotens mit base64-Dekodierung und shred zu verwalten.
Statt Datei-basierte Schlüssel manuell in Skripten zu verwalten, ist es viel sicherer und stabiler, den SSH-Schlüssel in einer ordnungsgemäßen SSH Private Key Credential in n8n zu speichern und diese Anmeldeinformation in den Authentifizierungseinstellungen des SSH-Knotens auszuwählen.
Eine Klarstellung zum __n8n_BLANK_VALUE_xxx, das Sie beim erneuten Öffnen der Anmeldedaten sehen: Das ist ein normales und erwartetes Verhalten, kein Datenverlust. n8n gibt den tatsächlichen Wert eines sensiblen Feldes (Password/Private Key) aus Sicherheitsgründen nach dem Speichern niemals an den Browser zurück — stattdessen wird ein Platzhalter-Token angezeigt. Der Schlüssel wird ordnungsgemäß auf dem Server gespeichert; was Sie auf dem Bildschirm sehen, ist nicht sein echter Inhalt.
Das eigentliche Problem entsteht eher durch die Verwendung eines Ausdrucks zum Ausfüllen des Feldes:
Das Feld Private Key ist ein einfaches mehrzeiliges Textarea: Es gibt keinen Grund, einen Ausdruck zu verwenden, um die Zeilenumbrüche beizubehalten. Fügen Sie den Schlüssel direkt ein (Strg+V), mit seinen echten Zeilenumbrüchen — das funktioniert nativ. Die Verwendung eines Ausdrucks hier vermischt die Logik der Laufzeitauflösung mit der Maskierung des sensiblen Feldes, was den Fehler erklären könnte, wenn der SSH-Knoten versucht, den Wert aufzulösen.
Wenn die Zeilenumbrüche nach direktem Einfügen immer noch abgeflacht erscheinen, überprüfen Sie den Quellschlüssel: Fügen Sie ihn zunächst in einen reinen Text-Editor ein, um zu bestätigen, dass er echte Zeilenumbrüche enthält (und nicht literale \n), bevor Sie ihn in n8n einfügen — einige Passwortmanager oder Terminals komprimieren das PEM-Format beim Export auf eine einzelne Zeile.
Hey! Du bist auf eine ziemlich berüchtigte n8n-Eigenheit gestoßen: das direkte Speichern von mehrzeiligen SSH-Privatschlüsseln in der Credential-UI.
Deine Beobachtung, dass sich das Feld in __n8n_BLANK_VALUE_... ändert, ist völlig richtig. Das ist n8ns Art, gespeicherte Anmeldedaten zu maskieren, aber es zerstört oft die Serialisierung mehrzeiliger Strings (wie RSA-Schlüssel), wenn du den Node wieder öffnest, was zum Fehler „Unsupported key format
Hallo, danke für die Antwort.
Der Inhalt im SSH-Node ist nicht das Problem. Ich kriege den SSH-Private-Key nicht nutzbar in den Credentials gespeichert. Der Schritt im Node ist noch ein Test und kommt aktuell noch gar nicht zur Anwendung.
Hallo, danke für die Antwort. Das Private Key Feld ist in der genannten Version eben einzeilig und nicht mehrzeilig. Deshalb ja der Trick mit der Expression, die augenscheinlich in der Prüfung auch funktioniert. Erst wenn ich die Credentials nutze, scheitert es wieder.
-----BEGIN PRIVATE KEY----- ist PKCS#8, das der SSH2-Parser hinter dem SSH-Node auch nicht akzeptiert, daher schlägt dieser Versuch fehl, bevor das Feld überhaupt beteiligt ist. Der Header, den du brauchst, ist -----BEGIN OPENSSH PRIVATE KEY-----.
Da das Feld den Schlüssel in deiner Version flacht, schreib die Credentials direkt ein, anstatt sie einzufügen. Exportiere die bestehende entschlüsselt:
Das landet in deinem bereitgestellten n8n-Volume, das du vom Host aus bearbeiten kannst. Füge den vollständigen OpenSSH-Schlüssel in privateKey als einzelnen JSON-String mit \n bei jedem Zeilenumbruch ein, dann importiere ihn über die gleiche ID zurück: