SSH Node Failure in n8n: 'Connection Closed by SSH Server - Current FSM is Disconnect' - Troubleshooting and Risks

Issue overview

When attempting to SSH from a self-hosted n8n instance to a router or other device, some users encounter a stateful error: the SSH server closes the connection and n8n transitions to a Disconnect FSM state. The error can stem from protocol mismatches, server-side limits, network middleboxes, or credential/configuration issues.

Significance for businesses

Workflows that depend on SSH to manage infrastructure, run remote scripts, or pull logs are vulnerable to brittle network and authentication conditions. Failures can cause automation gaps, delayed incident response, or incomplete configuration changes. For regulated environments, failed operations may also violate SLAs or compliance requirements.

What leaders should know

Connectivity issues are operational risks for any automation platform that reaches into infrastructure. Self-hosted deployments introduce additional network complexity (firewalls, NAT, jump hosts). Ensuring secure, resilient access patterns and appropriate telemetry is essential to keep automation reliable and auditable.

Recommended actions

1) Verify SSH server logs, accepted ciphers, and maximum concurrent sessions; ensure compatibility with the SSH client library n8n uses. 2) Check network path: firewall rules, NAT timeouts, and any intrusion prevention that might drop long-lived flows. 3) Use bastion hosts, keepalive settings, and retry/backoff strategies in workflows. 4) Add operational monitoring and alerting for SSH node failures, and maintain documented manual fallback procedures for critical tasks.