Almost every failed connection comes down to one of four things:
1) The credential is wrong
2) The host is unreachable
3) A firewall is in the way
4) The remote service is not listening
Every failure shows the exact error text from the connection attempt.
Authentication failed
Luumen reached the host and the host refused the credential.
Check the right credential is attached. If you rotated a key or added a new account, the host may still point at the old one. Use Try another credential, or edit the host.
Check the public key is on the host, in
~/.ssh/authorized_keysfor the account you connect as, with~/.sshat 700 and the file at 600.Check the username matches a real account. Using
ubuntuon a RHEL host is a common slip.Check the credential still works by testing it from Credentials against a host that uses it.
Check the uploaded key has no passphrase. Passphrase-protected keys are not fully supported when uploaded and fail the same way.
On Windows, confirm the account is a local administrator or in the Remote Management Users group.
Connection timed out
Luumen never reached the host at all.
Check the address and port. Defaults are 22 for SSH and 5985 for WinRM; 5986 is WinRM over HTTPS.
Check your network path. If you connect through a VPN, confirm it is up. If the host is behind a firewall, your address may need to be allowed.
Check the remote service. A host that is online but has
sshdstopped, or no WinRM listener, times out exactly like one that is switched off.Try a plain client. Running
ssh -v user@hostfrom your own terminal tells you quickly whether the problem is Luumen or the network.
Each connection attempt is allowed 60 seconds before Luumen reports a timeout.
Connection lost
The session was working and the connection broke, usually a network blip, a server-side disconnect, or an idle timeout.
Your scrollback is preserved. Luumen shows Reconnecting… and makes up to three attempts with an increasing delay before it reports Reconnect failed and offers Retry. If reconnecting keeps failing, treat it as a timeout and work through the checks above. Sessions that always drop after a period of quiet usually point at an idle timeout configured on the host, such as ClientAliveInterval in sshd_config. If tmux is on the host, whatever was running has kept running and reattaches when you reconnect.
Session ended
The session closed cleanly. You typed exit, or the remote shell exited on its own. This is not an error.
Host key changed
The key the server presents has changed. Luumen shows the key type and fingerprint and stops. That is expected after a rebuild, a restore, or a migration. It is also what a machine-in-the-middle attack looks like, which is why Luumen asks. Accept a changed host key only when you know why it changed.
Session persistence is unavailable on this host
Not an error, but worth understanding. The host has no tmux, or a version older than 1.8, so the shell runs as an ordinary session and will not survive a disconnect. Install tmux on the host if you want persistence; nothing in Luumen needs to change.
Windows and jump hosts
For Windows-specific checks see Connect to Windows hosts. When a host connects through a bastion, the bastion is dialed first, and a failure there stops everything behind it; the error names the jump host. Test the bastion on its own before assuming the target is the problem.
Still having issues?
Please contact [email protected] with the exact error text, the host operating system and version, whether a normal SSH client can reach it from the same machine, and anything that changed recently.