Chaves Privadas SSH em Credenciais

Perguntas
1

Qual é a mensagem de erro (se houver)?

Não foi possível conectar com essas configurações
Conexão SSH falhou: Cannot parse privateKey: Unsupported key format

Descrição

Tento configurar uma “Conta de Chave Privada SSH” nas Credenciais. Quando passo a chave para o campo “Chave Privada”, sempre recebo a mensagem de erro.

Parece que este campo destrói as quebras de linha da chave. Quando passo como expressão

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

parece funcionar na rotina de verificação do diálogo Nova Credencial.

No entanto: Quando uso as credenciais em um Nó SSH, recebo o mesmo erro novamente.
Quando volto para a credencial, o conteúdo do campo Chave Privada mudou para algo como __n8n_BLANK_VALUE_e5362baf-c777-4d57-a609-6eaf1f9e87f6.
O mesmo ocorre quando insiro a chave como expressão, fecho a janela de credenciais e a reabro imediatamente. Então a verificação da chave também falha.

Como posso armazenar chaves SSH no n8n sem que sejam destruídas?

Fluxo de trabalho

{
  "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. Converter string Base64 do formulário web n8n em um arquivo temporário e decodificar\necho \"{{ $json.vc_kf[0] }}\" | base64 -d \\ /tmp/temp_keyfile.key\n\n# 2. Definir permissões de arquivo extremamente restritivas (apenas este usuário pode lê-las)\nchmod 600 /tmp/temp_keyfile.key\n\n# 3. Executar VeraCrypt como Root (sem solicitação de senha graças ao 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. Destruir o arquivo de chave de forma absolutamente segura (irrevogável) do disco rígido\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"
  }
}

Informações sobre sua configuração n8n

  • Versão n8n: 2.30.7
  • Banco de dados (padrão: SQLite): padrão
  • Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main): padrão
  • Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker/CasaOS
  • Sistema operacional: Ubuntu 26.04 LTS
2

Oi @Me.MyBase

Observando o JSON que você forneceu, você está tentando lidar com arquivos de chave manualmente dentro de um nó Execute a command usando decodificação base64 e shred.

Em vez de gerenciar chaves baseadas em arquivo manualmente em scripts, é muito mais seguro e estável armazenar a chave SSH em uma Credencial de Chave Privada SSH adequada no n8n e selecionar essa credencial nas configurações de autenticação do nó SSH​.

Se você continuar recebendo uma mensagem “Unsupported key format” mesmo com uma chave PEM formatada corretamente, certifique-se de que a chave não possui uma frase de segurança ou, se tiver, verifique se você a inseriu corretamente no campo “Passphrase” da configuração de credencial.

3

Uma observação sobre o __n8n_BLANK_VALUE_xxx que você vê ao reabrir a credencial: é um comportamento normal e esperado, não uma perda de dados. n8n nunca retorna o valor real de um campo sensível (password/chave privada) para o navegador após o salvamento, por motivos de segurança — exibe um token placeholder em seu lugar. A chave está bem armazenada no servidor; o que você vê na tela não é seu conteúdo real.

O verdadeiro problema vem mais do uso de uma expressão para preencher o campo:

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

O campo Private Key é um simples textarea multilinha: não há necessidade de usar uma expressão para preservar as quebras de linha. Cole a chave diretamente (Ctrl+V), com seus verdadeiros saltos de linha — funciona nativamente. Usar uma expressão aqui mistura a lógica de resolução em tempo de execução com o mascaramento do campo sensível, o que pode explicar a falha quando o nó SSH tenta resolver o valor.

Se após uma colagem direta os saltos de linha parecem estar ainda compactados, verifique a chave de origem: cole-a primeiro em um editor de texto simples para confirmar que ela contém quebras de linha reais (e não \n literais) antes de colá-la em n8n — alguns gerenciadores de senhas ou terminais comprimem o formato PEM em uma única linha na exportação.

4

Obrigado por nos informar sobre isso. Criamos CV-16 como o ticket interno de desenvolvimento para investigar.

5

Olá! Você esbarrou em uma peculiaridade bastante conhecida do n8n: armazenar chaves SSH privadas de múltiplas linhas diretamente na interface de credenciais.

Sua observação sobre o campo mudar para __n8n_BLANK_VALUE_... é certeira. Essa é a forma que o n8n usa para mascarar credenciais salvos, mas muitas vezes quebra a serialização de strings com múltiplas linhas (como chaves RSA) quando você reabre o nó, resultando no erro “Unsupported key format”.

A solução mais robusta para contornar esses problemas de análise é usar variáveis de ambiente. Aqui está como corrigir especificamente para sua configuração Docker/CasaOS:

1. Prepare Sua Chave Privada (Uma única linha)
Substituia quebras de linha reais em seu arquivo PEM com \n. Deve ficar assim (mantenha as aspas):
"-----BEGIN RSA PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w...\n-----END RSA PRIVATE KEY-----"

2. Defina a Variável de Ambiente
Nas configurações do seu app CasaOS (ou docker-compose.yml), adicione uma nova variável de ambiente:
Nome: N8N_SSH_PRIVATE_KEY
Valor: [Sua chave de uma única linha do passo 1]
Salve e reinicie o contêiner n8n.

3. Atualize Sua Credencial n8n
Crie uma nova Conta SSH Private Key no n8n. No campo Private Key, em vez de colar a chave diretamente, use uma expressão para referenciar sua nova variável de ambiente:
={{ $env.N8N_SSH_PRIVATE_KEY }}

Isso injeta a chave bruta e formatada corretamente no cliente SSH em tempo de execução, contornando completamente a interface. Deve funcionar instantaneamente.

6

Oi @Me.MyBase Bem-vindo!
“Unsupported key format” é o analisador ssh2 rejeitando o conteúdo da chave, não a manipulação de quebras de linha na sua linha. A credencial SSH do n8n espera a chave no formato OpenSSH, e a sua é uma chave PEM clássica (-----BEGIN RSA PRIVATE KEY-----), que esse analisador não aceita. Converta-a no local, mesmo par de chaves para que o authorized_keys do servidor continue válido, e remova a frase de acesso para que nada precise ser descriptografado no momento da análise:

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

O cabeçalho deve mudar para -----BEGIN OPENSSH PRIVATE KEY-----. Cole a chave convertida completa, incluindo as linhas de cabeçalho e rodapé, e deixe o campo Passphrase em branco.

7

Olá, obrigado pela resposta.
O conteúdo no nó SSH não é o problema. Não consigo salvar a SSH Private Key de forma utilizável nas credenciais. A etapa no nó ainda é um teste e atualmente nem está sendo usada.

8

Olá, obrigado pela resposta. O campo Private Key é de uma só linha nessa versão mencionada, e não multilinha. É por isso que uso o truque com a Expression, que aparentemente também funciona na verificação. Só quando utilizo as credenciais é que falha novamente.

9

Também tentei o formato puro OpenSSL com o mesmo resultado. Coloquei isso no campo “Private Key” com um valor fixo (sem expressão)

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

-----BEGIN PRIVATE KEY----- é PKCS#8, que o analisador ssh2 por trás do nó SSH também não aceita, então essa tentativa falha no formato antes mesmo do campo estar envolvido. O cabeçalho que você quer é -----BEGIN OPENSSH PRIVATE KEY-----.
Como o campo achata a chave na sua versão, escreva a credencial diretamente em vez de colá-la. Exporte a existente descriptografada:

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

Isso fica no seu volume n8n montado para que você possa editá-lo do host. Coloque a chave OpenSSH completa em privateKey como uma única string JSON com \n em cada quebra de linha, depois importe-a de volta com o mesmo ID:

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

Reinicie o container e depois delete ssh.json, ele contém a chave em texto simples.