Remote-SSH: Connectivity issues with WALLIX Bastion requiring MFA (Browser OTP) + Interactive Password on Windows

I am opening this issue to report a persistent connectivity problem when using VSCode Remote-SSH through a specific bastion wallix setup. Despite several attempts to wrap the SSH connection, the interactive authentication flow seems to conflict with the extension's automation.

Problem Description
I am attempting to configure the VSCode Remote-SSH extension to connect to Linux servers through a WALLIX bastion. This setup requires a specific multi-factor authentication (MFA) flow:
1. Triggering a browser-based OTP validation
2. A manual Enter key press in the terminal
3. Manual password entry
While this workflow works perfectly in standard terminal emulators (e.g., MobaXterm or native CMD), it fails with VSCode Remote-SSH because the extension’s automation interferes with the interactive nature of the bastion’s authentication.
Environment
∙ Local OS: Windows 11 Enterprise
∙ VSCode Version: 1.96.2
∙ Remote-SSH Extension Version: 0.115.1
∙ Local SSH Client: Windows OpenSSH (OpenSSH_for_Windows_9.5p2)
∙ Jump Host: WALLIX Bastion
∙ Target OS: Ubuntu 24.04.3 LTS
Working Setup (Manual Terminal)
The authentication flow works correctly when using MobaXterm or CMD directly:
1. User initiates SSH connection
2. Browser opens for MFA validation (OTP)
3. User presses Enter in terminal
4. User enters password
5. Connection established successfully
The WALLIX .puttywab session files contain authentication strings in this format:username@domain@TARGET-SERVER:SSH:group:username@domain
SSH Configuration

Host TARGET
HostName bastion.example.com
Port 22
User username@domain@TARGET:SSH:group:username@domain
PreferredAuthentications keyboard-interactive
PubkeyAuthentication no
KbdInteractiveAuthentication yes
PasswordAuthentication yes
NumberOfPasswordPrompts 3
RequestTTY yes

Attempted Solutions & Results
Solution 1: SSH Wrapper with stdin redirection (< CON)
Created a batch wrapper to redirect stdin to the Windows console to allow manual MFA and password input.
Wrapper (ssh-wrapper.bat):

ssh -tt -o PreferredAuthentications=keyboard-interactive,password %HOST% < CON

Result: MFA and password authentication succeed. Shell connection is established and user can interact with the server manually. However, VSCode remains stuck at “Opening Remote” status indefinitely. The VSCode server installation phase never completes.
Server-side diagnostics show no vscode-server processes running for the connected user, while other users on the same server have active vscode-server processes. The ~/.vscode-server directory exists with binaries but the server fails to start during VSCode connection.
Solution 2: Removing stdin redirection
Modified wrapper to remove < CON:

ssh -tt -o PreferredAuthentications=keyboard-interactive,password %HOST%

Result: Authentication fails immediately. VSCode appears to send data to stdin prematurely, causing “Permission denied” errors right after the MFA validation step, before the user can manually enter the password.
Solution 3: Connection Reuse (ControlMaster)
Added to SSH config:

ControlMaster auto
ControlPath ~/.ssh/cm-%C
ControlPersist 10m

Result: Windows OpenSSH returns getsockname failed: Not a socket error. ControlMaster is not natively supported on Windows OpenSSH.
Solution 4: SSHFS Extension
Attempted using the SSHFS extension as an alternative to Remote-SSH.
Result: Connection times out during SSH handshake, or authentication order becomes incorrect (password prompt before MFA). The extension cannot handle WALLIX interactive authentication flow.
Root Cause Analysis
There is a fundamental conflict between WALLIX interactive requirements and VSCode’s automation:
∙ With < CON: The human authenticates successfully, but VSCode’s communication channel (stdin/stdout) is blocked, preventing server installation and operation
∙ Without < CON: VSCode’s automation tries to communicate before the human has finished the interactive auth flow, causing premature authentication failure
VSCode Remote-SSH expects fully automated SSH connections where it can pipe commands and data through stdin/stdout. WALLIX bastion requires sequential human interaction that cannot be automated.
Question
Is there a way to make VSCode Remote-SSH work with a WALLIX bastion requiring interactive MFA + password authentication on Windows?
Potential approaches to explore:
∙ SSH key-based authentication configuration with WALLIX (if supported by the bastion)
∙ ProxyCommand or ProxyJump configuration that might handle authentication separately
∙ Custom authentication method that separates human input phase from VSCode automation phase
∙ Alternative VSCode Remote-SSH configuration or settings
Current Workaround
Using MobaXterm to connect and mount remote folder via SSHFS, then opening the mounted drive in VSCode locally. This works but loses Remote-SSH benefits including remote extensions, proper integrated terminal, and seamless remote development experience.
Additional Context
∙ The same SSH configuration works perfectly when used manually from command line (cmd: ssh TARGET)
∙ Manual SSH connection via the wrapper succeeds consistently
∙ The issue is specifically VSCode Remote-SSH automation conflicting with interactive authentication
∙ Windows native SSH client is required due to corporate restrictions (WSL and Git Bash not available)
∙ Multiple users on target servers successfully use VSCode Remote-SSH with different (non-interactive) authentication methods​​​​​​​​​​​​​​​​

I am looking for a way to let the interactive authentication "finish" before VSCode starts its server installation sequence. If there are any hidden settings or ProxyCommand tricks that could help separate these phases, please let me know.

Start by reproducing the contrast between cmd: ssh TARGET and the VSCode Remote-SSH connection using the stated SSH configuration. Read ssh-wrapper.bat and compare its < CON and non-redirected behavior with the server-installation phase; the issue is done only when a supported configuration or a confirmed limitation for this WALLIX MFA flow is established.