🐛 Bug: Dory does not support external hardware OTP input for SSH authentication

[dory-finn]

Description

When connecting to an SSH server that requires OTP (One-Time Password) from an external hardware device (e.g., hardware token, MFA device), Dory currently fails to handle the interactive OTP input step.

As a result, SSH authentication fails even though credentials (password/key) are correct.

Error Messages

Observed errors include:

• All configured authentication methods failed
• SSH connection requires password
• No prompt for OTP / MFA code is shown

Expected Behavior

Dory should:

• Detect OTP/MFA prompt during SSH authentication
• Provide an input UI for users to enter OTP codes (e.g., from hardware token)
• Support interactive keyboard-based authentication (keyboard-interactive)

Actual Behavior

• SSH connection fails without allowing OTP input
• No UI or fallback mechanism for MFA/OTP
• Appears to only support password / key-based auth

Steps to Reproduce

1. Configure an SSH server with MFA (e.g., Google Authenticator / hardware token)
2. Attempt to connect via Dory
3. Observe that authentication fails without OTP prompt

Environment

• Dory version: (please fill)
• OS: (macOS / Windows / Linux)
• SSH server: (e.g., OpenSSH with MFA enabled)

Possible Root Cause

• Missing support for keyboard-interactive authentication in SSH client
• No handling of multi-step auth challenges

Suggested Fix

• Add support for keyboard-interactive auth flow
• Implement OTP prompt UI
• Support multiple challenge-response steps during SSH handshake

Additional Context

This issue blocks usage in environments with:

• Mandatory MFA
• Hardware security tokens
• Enterprise SSH setups

---

Would love to help test if a fix or experimental version is available 🙏

[solarhell]

@dorylab please review.

I reviewed Dory's current SSH flow and also inspected DBeaver's open-source implementation. I recommend solving this issue in the following way.

Recommendation

Do not introduce OTP as a new static SSH auth type.

Instead:

• keep the existing primary auth modes: password / private_key / agent
• treat OTP / MFA as part of SSH keyboard-interactive challenge-response
• only show an interactive prompt dialog when the SSH server actually requests it
• never persist OTP / challenge answers

Why this approach

This is closer to how mature DB GUIs handle enterprise SSH flows, especially DBeaver:

• config only stores primary auth type
• SSH layer includes keyboard-interactive in the auth flow
• UI prompts are handled by a dedicated prompt provider layer, not by adding a fixed OTP field to the main form
• “Test tunnel” and real tunnel setup go through the same underlying path

DBeaver references (commit 85febf59221f15ace55fce56ff501f5da91bc805):

• Auth types are only PASSWORD / PUBLIC_KEY / AGENT: SSHConstants.java
• JSch implementation includes keyboard-interactive in preferred auths: JSCHSessionController.java
• UI prompt provider handles promptKeyboardInteractive(...): JSCHUIPromptProvider.java
• Test tunnel uses the real tunnel initialization path: SSHTunnelDefaultConfiguratorUI.java

Current gap in Dory

Dory currently lacks interactive SSH challenge support:

• tunnel layer only handles password / private_key / agent, with no keyboard-interactive: apps/web/lib/connection/ssh/ssh-tunnel.ts
• SSH form only exposes Password / Private Key inputs, with no challenge UI: apps/web/app/(app)/[organization]/connections/components/forms/ssh/ssh-form.tsx
• test/connect APIs only support success/error, not an intermediate challenge-required state: apps/web/app/api/connection/test/route.ts

Proposed design

1. Keep the auth model simple

• do not add a persisted otp authMethod
• keep password / private_key / agent
• treat OTP as a runtime challenge, not a connection mode

2. Add keyboard-interactive support in the shared SSH tunnel layer

• enable tryKeyboard
• listen for keyboard-interactive
• convert server prompts into a structured challenge object
• continue the same SSH session after answers are submitted
• support multiple challenge rounds

3. Add a short-lived challenge coordinator

Because the challenge flow may span multiple HTTP requests, add a short-lived in-memory coordinator that:

• creates an auth attempt
• stores pending SSH challenge context / continuation
• returns a challengeId to the frontend
• resumes the original SSH auth session after answers are submitted
• cleans itself up on success / failure / timeout / cancel

Constraints:

• in-memory only
• TTL around 60-120 seconds
• do not persist OTP / challenge answers
• do not log challenge answers

4. Extend the API with a challenge_required state

Both test and connect should support:

• success
• challenge_required
• error

Suggested endpoints:

• POST /api/connection/test
• POST /api/connection/test/challenge
• POST /api/connection/connect
• POST /api/connection/connect/challenge

5. Add a dynamic challenge dialog in the frontend

• title from SSH name
• helper text from instructions
• inputs rendered dynamically from prompts[]
• echo=false rendered as password-style input
• support multiple prompts and multiple rounds
• support cancel / timeout / retry
• do not add a permanent OTP field to the main SSH form

6. Reuse the same flow for test and real connect

• Test Connection and real Connect should reuse the same interactive SSH auth path
• the only difference is what happens after tunnel readiness:
  • test runs ping / health check
  • connect continues pool / provider initialization

Security / runtime notes

• persist only long-lived SSH credentials: password / private key / passphrase
• never persist OTP, challenge answers, or transient prompts
• this design works naturally for Desktop and single-instance self-hosting
• multi-instance self-hosting would later require sticky routing or explicit challenge affinity

Suggested MVP scope

First iteration:

• single-instance in-memory challenge coordinator
• keyboard-interactive for a single SSH tunnel flow
• challenge-required support for both test/connect
• dynamic challenge dialog

Later improvements:

• jump-host interactive challenge
• better agent UX
• OpenSSH config / system SSH integration
• distributed challenge coordination