Claves privadas SSH en Credentials

Preguntas
1

¿Cuál es el mensaje de error (si lo hay)?

Couldn't connect with these settings 
SSH connection failed: Cannot parse privateKey: Unsupported key format

Descripción

Intento configurar una “Cuenta de clave privada SSH” en las Credenciales. Cuando paso la clave al campo “Clave privada” siempre obtengo el mensaje de error.

Parece que este campo destruye los saltos de línea de la clave. Cuando la paso como expresión

={{`-----BEGIN RSA PRIVATE KEY-----
*PEM-Format (RSA 4096-Bit)*
-----END RSA PRIVATE KEY-----
`}}

parece funcionar en la rutina de verificación del diálogo Nueva credencial.

Sin embargo: Cuando uso las credenciales en un nodo SSH obtengo el mismo error nuevamente.
Cuando vuelvo a la credencial, el contenido del campo Clave privada ha cambiado a algo como __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
Lo mismo ocurre cuando ingreso la clave como expresión, cierro la ventana de credencial y la reabro inmediatamente. Entonces la verificación de la clave también falla.

¿Cómo puedo almacenar claves SSH en n8n sin que se destruyan?

Flujo de trabajo

{
  "nodes": [
    {
      "parameters": {
        "authentication": "n8nUserAuth",
        "formTitle": "VeraCrypt Mount",
        "formFields": {
          "values": [
            {
              "fieldLabel": "Password",
              "fieldType": "password",
              "fieldName": "vc_pwd",
              "requiredField": true
            },
            {
              "fieldLabel": "Key-File",
              "fieldType": "file",
              "fieldName": "vc_kf"
            }
          ]
        },
        "responseMode": "lastNode",
        "options": {}
      },
      "type": "n8n-nodes-base.formTrigger",
      "typeVersion": 2.6,
      "position": [
        0,
        0
      ],
      "id": "4966f7da-16a6-49c8-ae0d-41f36fc5ada1",
      "name": "On form submission",
      "webhookId": "68c32594-ba38-4b59-875c-329b2aa3d8d7"
    },
    {
      "parameters": {
        "authentication": "privateKey",
        "command": "=# 1. Base64-String aus dem n8n-Webformular in eine temporäre Datei schreiben und decodieren\necho \"{{ $json.vc_kf[0] }}\" | base64 -d \\\\ /tmp/temp_keyfile.key\n\n# 2. Dateirechte extrem restriktiv setzen (nur dieser User darf sie lesen)\nchmod 600 /tmp/temp_keyfile.key\n\n# 3. VeraCrypt als Root ausführen (ohne Passwortabfrage dank visudo)\nsudo veracrypt --text --non-interactive --keyfiles=\"/tmp/temp_keyfile.key\" --password=\"{{ $json.vc_pwd }}\" --protect-hidden=no \"/mnt/Storage1/Diverses/Backup/System.bak\" \"/mnt/Storage1/frankenphp/www/img/external\"\n\n# 4. Das Keyfile absolut sicher (unwiderruflich) von der Festplatte schreddern\nshred -u /tmp/temp_keyfile.key"
      },
      "type": "n8n-nodes-base.ssh",
      "typeVersion": 1,
      "position": [
        208,
        0
      ],
      "id": "6e4353ce-36fc-4814-921b-73db4ec2d27b",
      "name": "Execute a command",
      "credentials": {
        "sshPrivateKey": {
          "id": "fMLJ7Uoza0CFhRy3",
          "name": "SSH Private Key account"
        }
      }
    }
  ],
  "connections": {
    "On form submission": {
      "main": [
        [
          {
            "node": "Execute a command",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  ],
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "f7540226fe43062b2dc4ccc946cf125acc99ca63606204c72cd424a5c9226c74"
  }
}

Información sobre tu configuración de n8n

  • Versión de n8n: 2.30.7
  • Base de datos (por defecto: SQLite): por defecto
  • Configuración de n8n EXECUTIONS_PROCESS (por defecto: own, main): por defecto
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio): Docker/CasaOS
  • Sistema operativo: Ubuntu 26.04 LTS
2

Hola @Me.MyBase

Observando el JSON que proporcionaste, estás intentando manejar archivos de clave manualmente dentro de un nodo Execute a command usando decodificación base64 y shred.

En lugar de gestionar claves basadas en archivos manualmente en scripts, es mucho más seguro y estable almacenar la clave SSH en una SSH Private Key Credential adecuada en n8n y seleccionar esa credencial dentro de la configuración de autenticación del nodo SSH​.

Si continúas recibiendo un error “Unsupported key format” incluso con una clave PEM correctamente formateada, asegúrate de que la clave no tenga una contraseña, o si la tiene, asegúrate de haberla ingresado correctamente en el campo “Passphrase” de la configuración de credenciales.

3

Una aclaración sobre el __n8n_BLANK_VALUE_xxx que ves al reabre la credencial: es un comportamiento normal y esperado, no una pérdida de datos. n8n nunca devuelve el valor real de un campo sensible (contraseña/clave privada) al navegador después de guardarlo, por razones de seguridad — muestra un token placeholder en su lugar. La clave se almacena correctamente en el servidor; lo que ves en pantalla no es su contenido real.

El verdadero problema viene más bien del uso de una expresión para rellenar el campo:

={{`-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
`}}

El campo Private Key es un simple textarea multilínea: no hay ninguna necesidad de pasar por una expresión para conservar los saltos de línea. Pega la clave directamente (Ctrl+V), con sus verdaderos saltos de línea — funciona de forma nativa. Usar una expresión aquí mezcla la lógica de resolución en tiempo de ejecución con el enmascaramiento del campo sensible, lo que puede explicar el fallo cuando el nodo SSH intenta resolver el valor.

Si después de un pegado directo los saltos de línea siguen pareciendo aplanados, verifica la clave fuente: pégala primero en un editor de texto plano para confirmar que contiene verdaderos retornos de carro (y no \n literales) antes de pegarla en n8n — algunos gestores de contraseñas o terminales comprimen el formato PEM en una sola línea en la exportación.

4

Gracias por avisarnos sobre esto. Hemos creado CV-16 como el ticket de desarrollo interno para investigarlo.

5

¡Hola! Has encontrado una peculiaridad bastante famosa de n8n: almacenar claves privadas SSH de múltiples líneas directamente en la interfaz de usuario de credenciales.

Tu observación sobre el campo que cambia a __n8n_BLANK_VALUE_... es muy acertada. Esta es la forma en que n8n enmascara las credenciales guardadas, pero a menudo rompe la serialización de cadenas de múltiples líneas (como claves RSA) cuando reabre el nodo, lo que genera el error „Unsupported key format

6

¡Hola @Me.MyBase, bienvenido!
«Unsupported key format» es el analizador ssh2 rechazando el contenido de la clave, no la manipulación de campos los saltos de línea. La credencial SSH de n8n espera la clave en formato OpenSSH, y la tuya es una clave PEM clásica (-----BEGIN RSA PRIVATE KEY-----), que ese analizador no aceptará. Conviértela en su lugar, mismo par de claves para que el authorized_keys del servidor siga siendo válido, y elimina la contraseña para que nada necesite desencriptarse en el tiempo de análisis:

ssh-keygen -p -N "" -f ./id_rsa

El encabezado debería cambiar a -----BEGIN OPENSSH PRIVATE KEY-----. Pega esa clave convertida completa, incluyendo las líneas de encabezado y pie de página, y deja el campo Passphrase en blanco.

7

Hola, gracias por la respuesta.
El contenido en el nodo SSH no es el problema. No puedo guardar la clave privada SSH de manera utilizable en las credenciales. El paso en el nodo es aún una prueba y actualmente no se está utilizando en absoluto.

8

Hola, gracias por la respuesta. El campo Clave privada es de una sola línea en la versión mencionada, no de varias líneas. Por eso el truco con la expresión, que aparentemente también funciona en la verificación. Solo cuando uso las credenciales, vuelve a fallar.

9

También intenté el formato puro de OpenSSL con el mismo resultado. Lo coloqué en el campo “Clave privada” con un valor fijo (sin expresión)

-----BEGIN PRIVATE KEY-----
*openssl genrsa* generated RSA 4096
-----END PRIVATE KEY-----
10

-----BEGIN PRIVATE KEY----- es PKCS#8, que el analizador ssh2 detrás del nodo SSH tampoco acepta, por lo que ese intento falla en el formato antes de que el campo se vea involucrado. El encabezado que quieres es -----BEGIN OPENSSH PRIVATE KEY-----.
Como el campo aplana la clave en tu versión, escribe la credencial directamente en lugar de pegarla. Exporta la existente descifrada:

docker exec -u node -it <your-n8n-container> n8n export:credentials --id=fMLJ7Uoza0CFhRy3 --decrypted --output=/home/node/.n8n/ssh.json

Eso se coloca en tu volumen n8n montado para que puedas editarlo desde el host. Pon la clave OpenSSH completa en privateKey como una única cadena JSON con \n en cada salto de línea, luego impórtala de nuevo con el mismo ID:

docker exec -u node -it <your-n8n-container> n8n import:credentials --input=/home/node/.n8n/ssh.json

Reinicia el contenedor, luego elimina ssh.json, contiene la clave en texto plano.