SSH node is getting an error "The connection is closed by SSH Server Current FSM is Disconnect"

Questions
1

Describe the problem/error/question

We are trying to SSH into a router from our self-hosted n8n server but we received this error: ‘The connection is closed by the SSH server. Current FSM is Disconnect.’ What should we check, and how do we fix this issue? All SSH credentials and connectivity are set up properly.

can’t sign in, instance unavailable), please contact support at help@n8n.io -->What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the 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"
  }
}

Share the output returned by the last node

<{
“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)”
]
}
}

Information on your n8n setup

  • **n8n version:**2.18.5
  • Database (default: SQLite):SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system:
2

Thanks for letting us know about this, We have created CV-5 as the internal dev ticket to look into it.

3

Hi @ibtihal Welcome!
The SSH node runs on the ssh2 library, which won’t negotiate the legacy key exchange, cipher and host key algorithms that Huawei/Comware style routers (your display version command) still require, so the router drops the session and you get “Current FSM is Disconnect”. The node has no field to add those algorithms.
Route through a jump host instead: a small Linux box that can speak the legacy algorithms. Point the SSH node at that box, and have it run the router command with the old options, for example:

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

See this:

4

We have taken a look at this issue and have confirmed that this does look likely to be a bug, It has been passed to one of our engineering teams to be resolved.

5

Hi, thank you for the explanation.

Could you please clarify which specific SSH key exchange, cipher, and host key algorithms are supported or used by the n8n SSH node (ssh2 library)?

6

Those are the ssh2 library defaults, and the node ships no algorithms option to change them, so this list is exactly what it offers on the wire.

Offered by default:

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

Compiled into ssh2 but never offered unless passed explicitly, which the node can’t do:

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 is already in the default host key list, so the host key is not where your router is failing. The gap is the kex and cipher, typically diffie-hellman-group14-sha1 paired with aes128-cbc or 3des-cbc on that class of device. If the router can be configured to also accept diffie-hellman-group14-sha256 and aes128-ctr, the SSH node reaches it directly and the jump host stops being necessary.