SSH — Connections & Authentication

Purpose

Pick the right auth pill for a given server before getting into any one method's specifics — the Add/Edit SSH Host modal's Authentication tab has 13 pills, grouped here by category.

How to do it

1. 1Credential-based : Password, Key only, Key + Password (key first, password fallback), Key + Interactive (key, then answer prompts like an OTP).
2. 2Fully interactive : MFA/Interactive — standalone keyboard-interactive, the server drives every prompt (password, OTP, Duo push); nothing is stored locally.
3. 3Delegated to something else already running : SSH Agent — hands signing off to your local ssh-agent/Pageant; works for plain keys AND FIDO2/security keys.
4. 4Hardware-backed, built into MangoSSH itself : PKCS#11 (external YubiKey/smartcard) and Windows Hello / Secure Enclave (uses your PC's own TPM or Mac's Secure Enclave — no external hardware to buy).
5. 5External secret managers (password fetched at connect time, nothing cached in MangoSSH): pass, Bitwarden, AWS SSM, Doppler, 1Password.
6. 6Certificate-based delegate : HashiCorp Vault SSH, configured on the Delegate tab, not the Authentication pill row — MangoSSH requests a short-lived signed certificate from your Vault server per connection.

How to verify

1. 1Run ssh -v user@host from a regular terminal (Windows Terminal, macOS Terminal, or any shell with OpenSSH installed) before configuring anything in MangoSSH.
   • Look in the output for lines containing "Authentications that can continue" — this lists exactly which methods the server actually offers (e.g. publickey,password ), and that's your answer for which pill to pick, not guesswork.
2. 2In MangoSSH, add the host, pick the pill that matches what step 1 found, fill in only the fields that pill's section shows (the other auth sections stay hidden), and click Add host .
3. 3Click the new sidebar entry once.
   • Expect the status dot to turn green and a shell prompt to appear within a few seconds — if instead you get stuck on a spinner or an error banner appears at the top of the terminal pane, the pill you picked doesn't match what the server offered; re-check step 1's output.

Troubleshooting

• Not sure which method the server actually supports?
  • Run ssh -v user@host from a regular terminal once — its output lists exactly which auth methods the server offered, which tells you which MangoSSH pill to pick.

Purpose

The everyday case — a server that accepts a password, a private key, or wants both (key first, password as fallback).

How to do it

1. 1Password : pick the Password pill, type it in, optionally check Save password to store it in your OS keychain (skipped if Personal Vault is locked).
2. 2Key only : pick Key only, Browse to the private key file (or generate one first under Settings → SSH Keys), enter the passphrase if the key is encrypted, optionally check Save passphrase .
3. 3Key + Password : same key fields, plus a password field used only if the server rejects the key.
4. 4SSH certificates : on the Key form, optionally set an SSH Certificate file (an OpenSSH user cert) alongside the key — MangoSSH presents both to the server for CA-based access, and can additionally check the cert against a KRL (Key Revocation List) file before connecting.

How to verify

1. 1Password pill : type the password, check "Save password", click Add host, then connect.
   • Expect a shell to open with no password prompt shown by MangoSSH at all (it's sent automatically).
   • Disconnect, then edit the host and confirm the password field shows as already saved rather than blank.
2. 2Key only pill : Browse to your private key file, connect.
   • Expect a shell to open directly.
   • Then deliberately point the Key file field at the WRONG key file, save, and reconnect — expect the connection to fail outright with no password fallback (proving "only" really means only).
3. 3Key + Password pill : repeat the wrong-key test above, but on this pill.
   • Expect MangoSSH to fall back to prompting for/using the saved password instead of failing outright — this is the one concrete behavioral difference from Key only.
4. 4Certificates : before connecting, run ssh-keygen -Lf your-cert.pub in a separate terminal and note the "Valid:" date range and "Principals:" list it prints.
   • Connect in MangoSSH and confirm it succeeds — then, separately, set the KRL field to point at a KRL file that revokes this same certificate's serial ( ssh-keygen -kf krl -z < serial > ca.pub ), reconnect, and confirm MangoSSH now refuses the connection specifically because of the revocation (not a generic auth failure).

Troubleshooting

• "Permission denied (publickey)" — the server doesn't have your public key in ~/.ssh/authorized_keys for that user, or the key file path/passphrase in MangoSSH is wrong.
  • Confirm the exact public key MangoSSH is using matches what's installed server-side.
• Certificate rejected even though it looks valid — check the KRL field: if a revocation list is set and the cert's serial is listed as revoked, MangoSSH refuses to connect on purpose.
  • Remove or update the KRL path if it's stale.
• Passphrase prompt every time despite "Save passphrase" — Personal Vault may be in plain mode or locked; saved secrets only round-trip through the OS keychain when the vault can actually unlock at read time.

Purpose

• Servers that require a live back-and-forth — a password prompt followed by a TOTP code, or a Duo/PagerDuty push notification — where no single static credential exists to save.
• This is different from Key + Interactive: MFA/Interactive never presents a key at all — the server drives 100% of the conversation via PAM.

How to do it

1. 1Pick the MFA (Interactive) pill.
   • No credential fields to fill in — there's nothing to save.
2. 2Connect.
   • MangoSSH surfaces each prompt the server sends (e.g. "Password:", then "Verification code:") as an interactive dialog; type each answer and submit.

How to verify

1. 1Pick the MFA (Interactive) pill, click Add host, then click the sidebar entry to connect.
   • Expect a prompt dialog to appear over the terminal pane titled with the server's own challenge text (typically "Password:") — type your password and submit.
2. 2Expect a second prompt to appear immediately after (e.g. "Verification code:" for a TOTP-gated server, or a message telling you to approve a push) — answer it the same way.
3. 3Expect the shell to open only after every prompt the server sends has been answered — if the server would normally show a third prompt in a plain ssh session (test this once with the CLI side by side to be sure) and MangoSSH stops after only two, that's the sign a PAM module isn't fully supported yet.

Troubleshooting

• Push notification (Duo, etc.) never arrives — this is entirely server/IdP-side; confirm the same push works via a plain SSH client from the same network before assuming MangoSSH is at fault.
• Prompt dialog appears but submitting does nothing — the server may have already timed out the challenge; cancel and reconnect to get a fresh prompt.

Purpose

Delegate signing to an agent process you already run — useful if you use the same keys across many tools, or if your key is a hardware FIDO2/security key that only an agent knows how to talk to.

How to do it

1. 1Make sure an SSH agent is running and has your key loaded ( ssh-add -l should list it) — Pageant on Windows, ssh-agent on macOS/Linux, or a FIDO2-aware agent for security keys.
2. 2Pick the SSH Agent pill.
   • No key file/passphrase to configure — MangoSSH talks to whatever agent is already running.
3. 3Connect.
   • For a FIDO2/security key ( sk-ssh-ed25519 / sk-ecdsa ), your key's own touch prompt fires during the handshake.

How to verify

1. 1Open a terminal (outside MangoSSH) and run ssh-add -l .
   • Expect at least one key fingerprint listed — if it says "The agent has no identities.", stop and fix that first (run ssh-add /path/to/key ) before touching MangoSSH at all.
2. 2In MangoSSH, pick the SSH Agent pill (no fields to fill in), click Add host, then connect.
   • Expect a shell to open with no key-file or password prompt from MangoSSH.
3. 3For a FIDO2/security key specifically: watch for the key's own physical prompt (an LED blink and/or a require-touch state) at the moment you click connect.
   • Touch it and expect the shell to open within a few seconds; if nothing on the physical key lights up at all, the agent isn't relaying the request to the device — see below.

Troubleshooting

• "Agent has no identities" — the agent is running but empty; run ssh-add /path/to/key (or re-insert/re-register the security key) before retrying.
• Works from a terminal's own ssh but not MangoSSH — confirm MangoSSH and your terminal are pointed at the same agent socket/pipe; on Windows this usually means confirming both use Pageant (or both use the same OpenSSH agent service), not one of each.

Purpose

• The strongest practical option: the private key material never exists in software at all, whether on an external token (PKCS#11) or your PC's own built-in secure hardware (Windows Hello / Secure Enclave).
• Every connect requires the physical gesture — a PIN + touch, or a biometric prompt.
• PKCS#11 : for an external YubiKey (PIV mode) or a CAC/PIV government smartcard.
• RSA keys only in the current release.
• Windows Hello : a non-exportable key generated inside your PC's TPM (RSA 2048) or Mac's Secure Enclave (ECDSA P-256) — no extra hardware to buy.
• One Windows Hello key is reused across every host using this method; generate it once, then copy its public line onto each server.
• sign this signature MangoSSH asks for a signature TPM / Secure Enclave private key lives here only SSH server verifies pubkey MangoSSH never receives the private key itself — it sends the data to be signed to the hardware, and gets back only a signature.

How to do it

1. 1PKCS#11 : pick the PKCS#11 pill, enter/browse to your PKCS#11 module path (the vendor's .dll / .so — e.g. Yubico's ykcs11 ), click Detect Keys to list what's on the inserted token, pick the key from the dropdown (its placeholder reads "— Click 'Detect Keys' first —" until you do), enter/remember the PIN.
2. 2Windows Hello : pick the Windows Hello pill, click Generate Key — this triggers a real Windows Hello (or Touch ID) prompt once.
   • On success the status line changes to "Key ready." and shows the resulting public key line below it.
3. 3Copy the shown public key line into the target server's ~/.ssh/authorized_keys .

How to verify

1. 1PKCS#11 : with the token inserted, click Detect Keys.
   • Expect the status text next to the button to update and the key dropdown to populate with at least one entry (no longer showing the "Click 'Detect Keys' first" placeholder).
   • Unplug the token and click Detect Keys again — expect it to now find nothing; replug and confirm it finds the key again.
2. 2Windows Hello : click Generate Key.
   • Expect a real Windows Hello (fingerprint/face/PIN) or Touch ID prompt to appear immediately — not a silent success.
   • Complete the gesture and confirm the status line changes to exactly "Key ready." with a real ssh-rsa AAAA… line shown underneath.
3. 3Add the shown public key to a test server's authorized_keys , connect using this host entry, and confirm a fresh Windows Hello/Touch ID prompt fires again on this connect — every connect should re-prompt, not just the first one.
4. 4Cancel that connect-time prompt deliberately once.
   • Expect the connection to fail cleanly with an auth error rather than MangoSSH silently retrying or falling back to another method.

Troubleshooting

• PKCS#11 "Detect Keys" finds nothing — confirm the token is actually in PIV mode (not just plugged in) and that the module path points at a real, architecture-matching (32 vs 64-bit) PKCS#11 library.
• Windows Hello "Generate Key" fails immediately — Windows Hello itself must be set up (a PIN, fingerprint, or face enrolled in Windows Settings) before MangoSSH can use it; hardware presence alone isn't enough.
• Connect succeeds but no Hello/Touch ID prompt appeared — this would mean the gesture requirement isn't being enforced; treat this as a bug worth reporting rather than a convenience.

Purpose

Fetch the password from a secrets manager you already use at connect time, so MangoSSH never stores the credential itself at all — only a pointer to where it lives.

How to do it

1. 1pass (passwordstore.org): requires pass + gpg-agent unlocked; Unix-only in practice.
2. 2Bitwarden : requires the bw CLI; MangoSSH prompts for your Bitwarden master password once per MangoSSH session, then reuses the unlocked session.
3. 3AWS SSM Parameter Store : fetched via aws ssm get-parameter --with-decryption , using the AWS CLI's own existing credential chain (env vars, ~/.aws/credentials , SSO, or an instance role).
4. 4Doppler : fetched via doppler secrets get --plain ; requires doppler login to have been run already.
   • 5 1Password : fetched via op read op://vault/item/field ; requires op signin or the desktop app's CLI integration.
   • 6 For each, pick the matching pill and fill in whatever reference field it asks for (a pass-store path, a Bitwarden item name, an SSM parameter name, a Doppler secret name, or a 1Password op:// URI).

How to verify

1. 1Before touching MangoSSH, open a terminal and run the exact CLI command by hand — e.g. for 1Password: op read op://vault/item/field .
   • Expect it to print the real secret value directly to your terminal.
   • If this step fails, fix it here first (log in, unlock the vault, etc.) — MangoSSH will fail the exact same way and for the exact same reason.
2. 2In MangoSSH, pick the matching pill, paste in the same reference (vault/item/field, SSM parameter name, etc.) you just tested, click Add host, then connect.
3. 3Expect the shell to open with NO password prompt shown anywhere in MangoSSH — the secret was fetched in the background using the reference you gave it.
   • If a password prompt appears instead, MangoSSH couldn't resolve the reference and silently fell through; check the reference string for typos first.

Troubleshooting

• "command not found" -style failure — the relevant CLI isn't installed or isn't on PATH for the account MangoSSH runs as.
• Fetch works by hand but fails from MangoSSH — check whether the CLI relies on an interactive login session (e.g. a browser-based SSO flow) that doesn't carry over to a background call — some of these tools need a one-time interactive login before non-interactive calls will succeed.

Purpose

Get a short-lived, centrally-issued SSH certificate per connection instead of a long-lived static key — the standard pattern for organizations already running HashiCorp Vault's SSH secrets engine.

How to do it

1. 1Open the host's Delegate tab (not the Authentication pill row — this is a separate, additive feature).
2. 2Under "HashiCorp Vault SSH", enter your Vault server address, the SSH secrets engine mount path, the role name, and how MangoSSH should authenticate to Vault itself.
3. 3This overrides any static certificate file configured on the Key auth tab — Vault SSH, when configured, always takes precedence.

How to verify

1. 1Before connecting, run vault write ssh/sign/ < role > public_key=@~/.ssh/id_ed25519.pub by hand (matching your configured mount/role) and confirm Vault itself issues a certificate — this isolates a Vault ACL/role problem from a MangoSSH problem before you even open the app.
2. 2In MangoSSH, check the Delegate tab's Verbose/debug mode checkbox on this host, then connect and open the Debug panel.
   • Expect to see a step where MangoSSH requests a certificate from Vault BEFORE the SSH handshake step appears — if that step is missing, the Vault SSH fields aren't actually being used.
3. 3Expect the shell to open normally.
   • Separately, run ssh-keygen -Lf against the issued certificate file (check your Vault role's configured TTL — it should be short, minutes to hours, not years) to confirm the validity window matches what you configured in Vault, not a long-lived static cert.

Troubleshooting

• "permission denied" from Vault itself — a Vault ACL/policy problem, not a MangoSSH problem; test the same Vault SSH role directly via the vault CLI first.
• Cert issued but server still rejects it — confirm the target server's sshd_config actually trusts your Vault CA's public key via TrustedUserCAKeys .

Purpose

• Connect to a server that isn't directly reachable — it sits behind a jump host, or behind a cloud provider's session-broker (AWS SSM, GCP IAP, Cloudflare Access, Teleport, Tailscale SSH, Azure Bastion) instead of a raw TCP listener at all.
• auth #1 auth #2 MangoSSH your machine Bastion host jump / gateway Target host the real server MangoSSH authenticates twice: once to the bastion (to open the tunnel), then again to the real target inside it.
• Each hop can use a different auth method.

How to do it

1. 1ProxyJump (bastion) : on the target host's Delegate tab, set Via SSH host to another already-saved MangoSSH host.
   • That saved host's own credentials open the tunnel; your target host's own auth method re-authenticates inside it.
2. 2Zero-trust ProxyCommand : on the same tab, either type a raw ProxyCommand (with %h / %p / %r placeholders) or pick a Quick preset for AWS SSM Session Manager, GCP IAP, Cloudflare Access, Teleport ( tsh ), Tailscale SSH, or Azure Bastion, then fill in the instance/tunnel-specific placeholders it leaves blank.
3. 3The relevant CLI (aws/gcloud/cloudflared/tsh/tailscale/az) must already be installed, on PATH, and logged in — MangoSSH runs it as a subprocess and pipes its stdio as the SSH stream, exactly like OpenSSH's own ProxyCommand.

How to verify

1. 1ProxyJump : on the target host's Delegate tab, pick a saved bastion host from the "Via SSH host" dropdown, save, then connect to the target directly (not the bastion).
   • Expect only ONE terminal to open (for the target) — you are not separately asked to connect to the bastion first.
2. 2On the target host (once connected), run who -m or echo $SSH_CONNECTION and confirm the source IP shown is the bastion's IP, not your own machine's — this is the concrete proof traffic actually routed through the bastion rather than connecting directly.
3. 3ProxyCommand : before configuring MangoSSH, copy the exact command string from the Quick preset, substitute a real hostname for %h (and %p / %r if present), and run it by hand in a terminal.
   • Expect it to hang open in a piped/tunneled state (not exit immediately) — that's what confirms the broker CLI itself works before MangoSSH ever calls it.
4. 4Paste the real (non-substituted) command into the ProxyCommand field, save, and connect.
   • Expect the same behavior as the manual test — a live shell, no broker-side error.

Troubleshooting

• Bastion connects but target hop fails — the target host's own auth method is what runs inside the tunnel; troubleshoot it exactly as you would a direct connection to that host.
• ProxyCommand preset fails with an auth/session error from the CLI itself — that broker's own login has expired (e.g. AWS SSO token, tsh login session) — re-authenticate that CLI outside MangoSSH first.

Purpose

Set a default bastion and/or a default credential once on a Group, so every host you add to that group can skip repeating it — useful for a fleet of similar servers (e.g. "Production" all going through the same bastion with the same service account).

How to do it

1. 1Open Settings → Groups, create or select a group, and set its default bastion and/or default credential (auth method + key path / password, stored the same way a host's own credential is).
2. 2When adding or editing a host, assign it to that group and leave its own bastion/credential fields empty — the group's defaults fill in automatically at connect time.
3. 3A host's own explicit setting always wins over the group's default — inheritance only fills a gap, it never overrides something you've set directly on the host.

How to verify

1. 1In Settings → Groups, set a specific bastion on a test group (e.g. "QA").
   • Add a NEW host, assign it to "QA", and leave its own "Via SSH host" field on the Delegate tab empty (don't pick anything there).
2. 2Connect to the new host.
   • On the target, run who -m and confirm the source IP is the GROUP's bastion IP — proving the inherited default actually applied even though you never touched that host's own bastion field.
3. 3Now edit that same host and explicitly set its own "Via SSH host" to a DIFFERENT saved bastion.
   • Reconnect and confirm who -m now shows the host's own bastion's IP, not the group's — proving the host-level setting overrides the group default rather than being ignored or conflicting with it.

Troubleshooting

• Inheritance doesn't seem to apply — check Settings → Host visibility / the group assignment on the host itself; a host with no group, or the wrong group, won't inherit anything.
• An SSH group and an RDP group of the same name behave independently — this is correct: groups are scoped per-protocol internally, so a same-named SSH and RDP group never cross-contaminate credentials.

Purpose

Understand MangoSSH's first-connect trust prompt — the single most important security decision point in the whole app — and how KRL revocation checking backs it up for certificate-based auth.

How to do it

1. 1The first time you connect to a host:port MangoSSH has no record of, an "Unknown host key" dialog shows the host, key type, and fingerprint, with No, cancel and Yes, trust & connect — clicking the backdrop or Esc also counts as cancel (the prompt fails closed, never open).
2. 2This is expected the very first time you connect anywhere.
   • It is not expected on a host you've connected to before with no prompt — that combination specifically can indicate a man-in-the-middle attack.
3. 3If you legitimately rebuilt a server (new host key expected), you can forget the stored key for that host (via the host's context menu) so the next connect re-prompts cleanly.

How to verify

1. 1On the target server, run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub (or the matching key-type file it actually uses) and note the fingerprint it prints.
2. 2Connect to that host for the first time in MangoSSH.
   • Expect the "Unknown host key" dialog to show a fingerprint — compare it character-for-character against what step 1 printed.
   • They should match exactly.
3. 3Click Yes, trust & connect and confirm the shell opens.
   • Disconnect and connect again — expect NO prompt this second time (the key is now remembered).
4. 4Right-click the host → forget its stored key (if available in the context menu) or otherwise clear it, then reconnect.
   • Expect the unknown-host-key prompt to reappear, proving "forget" genuinely resets trust rather than just hiding the warning.
5. 5With a KRL configured (Password & Key-Based Authentication use case): connect using a certificate whose serial is listed in the KRL and confirm the connection is refused with a revocation-related error, not a generic auth failure.

Troubleshooting

• Prompt appears on a host you've connected to for months — do not click through it reflexively.
  • Confirm out-of-band (call the server's admin, check change records) that the server's host key was intentionally rotated before accepting.
• Certificate auth fails with no explanation after adding a KRL — the KRL path only applies when a certificate file is also set; double-check both fields together.

Purpose

Capture what happened in a session after the fact — either a full terminal replay, or the target server's own authentication log, or a live connect-pipeline trace for troubleshooting the SSH handshake itself.

How to do it

1. 1Always record sessions (Delegate tab): every session for this host is silently captured as an asciicast under recordings/ < host > / in the app data folder — no separate "start recording" step needed.
2. 2Follow server sshd log (Delegate tab, POSIX targets only): MangoSSH tails the target's own sshd log over the same authenticated session and streams parsed login/failure/disconnect events into the local Audit Log.
3. 3Verbose / debug mode (Delegate tab): emits an event at every connect-pipeline checkpoint (algorithm negotiation, TCP path, host-key verdict, auth method + result, PTY/shell request) — viewable live via the Debug toolbar button while the session runs.

How to verify

1. 1Check "Always record sessions", save, connect, type a couple of commands, then disconnect.
   • Browse to recordings/ < host > / in the app data folder and expect a new .cast file with a timestamp matching when you just connected.
2. 2Check "Follow server sshd log" on a POSIX host, save, and connect normally once (success).
   • Then, from a completely separate machine/terminal, attempt an SSH login to the SAME host with a deliberately wrong key or password.
   • Open Settings → Audit Log and expect a failed-login entry to appear for that second attempt, tagged with the connecting IP.
3. 3Check "Verbose / debug mode", save, and connect.
   • Click the Debug icon in the session toolbar WHILE connecting (or immediately after).
   • Expect a running log of checkpoints in order: algorithm negotiation, TCP connect, host-key verdict, auth method + result, then PTY/shell request — not just a single "connected" line.

Troubleshooting

• sshd log following shows nothing — confirm the target is POSIX (this feature is explicitly not supported on Windows targets) and that the connecting user has read access to the server's own sshd log.
• Debug mode shows a failure at the algorithm-negotiation step — see Algorithm Policy below; the server may require a KEX/cipher/MAC MangoSSH's current policy doesn't offer.

Purpose

Enable X11/agent forwarding for a specific host, and control exactly which SSH algorithms are offered — either loosened for an old/embedded device, or tightened to modern-only for a hardened environment.

How to do it

1. 1X11 forwarding (Delegate tab): requires a local X server running (VcXsrv/X410 on Windows, XQuartz on macOS) to actually display anything remote.
2. 2Agent forwarding (Delegate tab): lets commands run on the remote host use your local ssh-agent/Pageant in turn (e.g. to git clone from that remote using your local key) — only enable this for hosts you trust, since a compromised remote can then also try to use your agent.
3. 3Auto-reconnect on session drop (Delegate tab): retries silently with capped exponential backoff (1s, 2s, 4s, 8s, 16s, 30s cap, max 10 attempts) — only works transparently when the credential is a cached password/passphrase, not a live interactive prompt.
4. 4Strict mode (Advanced tab): restricts to modern algorithms only — no ssh-rsa , no SHA-1, no CBC ciphers.
5. 5Manual KEX / host-key / cipher / MAC selection (Advanced tab): leave everything unchecked to use MangoSSH's defaults; only override for a server with unusual requirements (e.g. an old network appliance needing a legacy KEX).

How to verify

1. 1X11 : start your local X server (VcXsrv/XQuartz), check X11 forwarding, connect to a Linux host, and run xclock (or xeyes ).
   • Expect a small clock/eyes window to appear on your local desktop within a couple of seconds, not just text output in the terminal.
2. 2Agent forwarding : check it, connect, then run ssh-add -l ON the remote host (inside the session, not locally).
   • Expect the SAME key fingerprint you'd see running that command on your own machine — proof your local agent is genuinely reachable from the far side.
3. 3Auto-reconnect : connect using an auth method with a cached secret (e.g. saved Password), then kill the connection from the server side (e.g. restart sshd, or drop the network briefly).
   • Expect MangoSSH to reconnect on its own within the backoff window (up to ~30s) without you clicking anything.
4. 4Strict mode / manual algorithm selection : enable Verbose/debug mode alongside whichever policy you set, connect, and check the Debug panel's algorithm-negotiation line.
   • Expect the negotiated KEX/cipher/MAC to be from the modern-only set (Strict mode) or to match your manual selection exactly — not a legacy algorithm slipping through.

Troubleshooting

• X11 forwarding does nothing — almost always means no local X server is actually running, not an MangoSSH-side problem.
• Auto-reconnect doesn't kick in — check whether the auth method requires a live prompt (MFA/Interactive, a token touch) — those inherently can't auto-reconnect unattended, by design.
• Strict mode breaks a connection that worked before — the server is offering only legacy algorithms; either fix the server's sshd_config , or turn Strict mode off for that specific host.