Nó SSH está apresentando um erro "The connection is closed by SSH Server Current FSM is Disconnect"

Descreva o problema/erro/pergunta

Estamos tentando fazer SSH em um roteador a partir do nosso servidor n8n auto-hospedado, mas recebemos este erro: ‘The connection is closed by the SSH server. Current FSM is Disconnect.’ O que devemos verificar e como corrigimos este problema? Todas as credenciais SSH e conectividade estão configuradas adequadamente.

can’t sign in, instance unavailable), please contact support at help@n8n.io

Qual é a mensagem de erro (se houver)?

Compartilhe seu workflow

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
{
  "nodes": [
    {
      "parameters": {},
      "type": "n8n-nodes-base.manualTrigger",
      "typeVersion": 1,
      "position": [
        -192,
        144
      ],
      "id": "2df66140-18f8-4cfb-8e88-f3b9551038ca",
      "name": "When clicking 'Execute workflow'"
    },
    {
      "parameters": {
        "command": "display version"
      },
      "type": "n8n-nodes-base.ssh",
      "typeVersion": 1,
      "position": [
        16,
        144
      ],
      "id": "e947c9ba-d828-4490-8ad1-e5a99b5cf292",
      "name": "Execute a command",
      "alwaysOutputData": true,
      "credentials": {
        "sshPassword": {
          "name": "SSH Password account"
        }
      }
    }
  ],
  "connections": {
    "When clicking 'Execute workflow'": {
      "main": [
        [
          {
            "node": "Execute a command",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "3d1b8feb96140bbc11a6a410c27c7cb04f42940da43d0df2759b46942c8c8350"
  }
}

Compartilhe a saída retornada pelo último nó

{
“errorMessage”: “The connection is closed by SSH Server\r\nCurrent FSM is Disconnect”,
“errorDetails”: {},
“n8nDetails”: {
“n8nVersion”: “2.18.5 (Self Hosted)”,
“binaryDataMode”: “filesystem”,
“stackTrace”: [
“Error: The connection is closed by SSH Server\r”,
“Current FSM is Disconnect”,
" at DISCONNECT (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/client.js:342:25)“,
" at 1 (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/protocol/handlers.misc.js:53:16)”,
" at Protocol.onPayload (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/protocol/Protocol.js:2059:10)“,
" at GenericDecipherNative.decrypt (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/protocol/crypto.js:1269:26)”,
" at Protocol.parsePacket [as _parse] (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/protocol/Protocol.js:2028:25)“,
" at Protocol.parse (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/protocol/Protocol.js:313:16)”,
" at Socket. (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/ssh2@1.15.0/node_modules/ssh2/lib/client.js:775:21)“,
" at Socket.emit (node:events:508:28)”,
" at addChunk (node:internal/streams/readable:563:12)“,
" at readableAddChunkPushByteMode (node:internal/streams/readable:514:3)”
]
}
}

Informações sobre sua configuração n8n

  • Versão n8n: 2.18.5
  • Banco de dados (padrão: SQLite): SQLite
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Sistema operacional:

Obrigado por nos informar sobre isso, criamos CV-5 como o ticket de desenvolvimento interno para investigar.

Oi @ibtihal Bem-vindo!
O nó SSH funciona na biblioteca ssh2, que não negocia os algoritmos legados de troca de chaves, cifra e chave de host que os roteadores estilo Huawei/Comware (seu comando display version) ainda exigem, então o roteador encerra a sessão e você recebe “Current FSM is Disconnect”. O nó não possui um campo para adicionar esses algoritmos.
Roteie por um host de salto em vez disso: uma pequena caixa Linux que possa falar os algoritmos legados. Aponte o nó SSH para essa caixa e execute o comando do roteador com as opções antigas, por exemplo:

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 -oHostKeyAlgorithms=+ssh-rsa -oCiphers=+aes128-cbc user@router-ip "display version"

Veja isto:

Analisamos esta questão e confirmamos que parece ser um bug. O assunto foi encaminhado para um de nossos times de engenharia para ser resolvido.

Oi, obrigado pela explicação.

Poderia esclarecer quais algoritmos específicos de troca de chaves SSH, cifra e chave de host são suportados ou usados pelo nó SSH do n8n (biblioteca ssh2)?

Esses são os padrões da biblioteca ssh2, e o node não oferece nenhuma opção algorithms para alterá-los, portanto, esta lista é exatamente o que ele oferece na transmissão.

Oferecido por padrão:

kex:           curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha256, diffie-hellman-group15-sha512, diffie-hellman-group16-sha512, diffie-hellman-group17-sha512, diffie-hellman-group18-sha512
serverHostKey: ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, rsa-sha2-512, rsa-sha2-256, ssh-rsa
cipher:        chacha20-poly1305@openssh.com, aes128-gcm, aes128-gcm@openssh.com, aes256-gcm, aes256-gcm@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr
hmac:          hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha1-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1

Compilado no ssh2 mas nunca oferecido a menos que seja passado explicitamente, o que o node não consegue fazer:

kex:           diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1
serverHostKey: ssh-dss
cipher:        3des-cbc, aes256-cbc, aes192-cbc, aes128-cbc, arcfour256, arcfour128, arcfour, blowfish-cbc, cast128-cbc
hmac:          hmac-md5, hmac-sha2-256-96, hmac-sha2-512-96, hmac-ripemd160, hmac-sha1-96, hmac-md5-96

ssh-rsa já está na lista de chaves de host padrão, portanto, a chave de host não é onde seu roteador está falhando. A lacuna está no kex e cipher, tipicamente diffie-hellman-group14-sha1 emparelhado com aes128-cbc ou 3des-cbc nessa classe de dispositivo. Se o roteador puder ser configurado para também aceitar diffie-hellman-group14-sha256 e aes128-ctr, o node SSH o alcança diretamente e o host jump deixa de ser necessário.