Codex desktop app remote SSH fails when server requires keyboard-interactive/PAM after public-key auth
What happened?
The Codex desktop app remote SSH connection fails against an OpenSSH server whose authentication policy requires both public-key auth and keyboard-interactive/PAM.
A normal terminal SSH client can connect to the same endpoint successfully, but Codex app remote SSH fails during the connection/auth flow. The user-facing error seen in the app was around kex_exchange_identification / key exchange identification, but server-side logs suggest the app is closing before completing the keyboard-interactive/PAM step.
SSH server auth policy
Relevant sshd_config settings:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive:pamSo public-key auth alone is intentionally insufficient; after the key is accepted, the client must also complete keyboard-interactive/PAM.
What works
From a normal terminal OpenSSH client, the same remote endpoint works when using the same host/port/key and completing the keyboard-interactive/PAM prompt.
Additional checks from the server side showed:
- the SSH daemon is listening normally on port 22
- the remote TCP tunnel is forwarding to the SSH daemon correctly
ncto the exposed endpoint receives a normal OpenSSH bannerssh -F /dev/null -vvv ...reaches SSH userauth and negotiates KEX successfully
The failure does not appear to be raw TCP reachability or SSH banner/KEX support.
Server-side logs during failing app attempts
Repeated failed Codex app attempts produce logs like:
Connection closed by authenticating user <redacted> 127.0.0.1 port <redacted> [preauth]
srclimit_penalise: 127.0.0.1/32: activating ipv4 penalty ... failed authentication
drop connection #0 from [127.0.0.1]:<redacted> on [127.0.0.1]:22 penalty: failed authenticationSuccessful terminal login shows:
Accepted keyboard-interactive/pam for <redacted> from 127.0.0.1 port <redacted> ssh2
pam_unix(sshd:session): session opened for user <redacted>Expected behavior
Codex app remote SSH should either:
- support OpenSSH
keyboard-interactive/ PAM continuation after public-key auth, or - detect/report that this SSH auth method is unsupported with a clear message.
It should not surface this as a key-exchange-style failure if KEX and the SSH banner are actually succeeding.
Why this matters
Many managed Linux servers require MFA/PAM/keyboard-interactive after public-key auth. Terminal SSH works in this setup, so users reasonably expect Codex app remote SSH to work or at least explain the unsupported auth method.
Environment
- Client: Codex desktop app remote SSH connection
- Server: OpenSSH on Linux
- Access path: TCP tunnel forwarding a public endpoint to local
sshdon port 22 - Password auth disabled
- Public-key plus keyboard-interactive/PAM required
I can provide additional sanitized logs if useful.
8 Comments
Small clarification: this does not appear to be FRP- or TCP-tunnel-specific. The exposed endpoint returns a normal OpenSSH banner, and a terminal OpenSSH client reaches userauth successfully.
The key detail is the server requires:
So a client that only completes publickey auth will fail even if KEX succeeds. The Codex app should either support the keyboard-interactive/PAM continuation or report that this auth mode is unsupported, instead of surfacing a key-exchange-style failure.
I’m encountering the same issue with Codex Desktop remote SSH.
My environment is an HPC system where SSH login requires keyboard-interactive/PAM authentication. VSCode Remote SSH can connect successfully using this flow, and I can access remote files normally through VSCode. However, Codex Desktop cannot complete the same remote SSH authentication flow, so I cannot use the native Codex Desktop app against the remote filesystem.
What I would like is for Codex Desktop remote connections to support the same class of SSH authentication flows that VSCode Remote SSH supports, especially keyboard-interactive/PAM and multi-step authentication used by university/HPC systems.
Expected behavior:
Codex Desktop should be able to connect to a host in
~/.ssh/configthat requires keyboard-interactive/PAM auth, assumingssh <host>or VSCode Remote SSH can connect successfully.Actual behavior:
VSCode Remote SSH works, but Codex Desktop remote connection fails because it does not appear to support the required keyboard-interactive login flow.
This is important for HPC/academic environments where users often cannot use simple direct key-only SSH authentication and cannot change the server auth policy.
I wonder why Codex Desktop remote SSH does not currently support keyboard-interactive/PAM authentication? Is this a known design limitation of the current remote-SSH implementation, a security decision, or simply a missing feature?
Same issue here.
I’m using Codex Desktop on Windows with a university HPC system. The server requires password + dynamic verification code through keyboard-interactive/PAM during SSH login. Normal terminal SSH works, and VS Code Remote SSH can connect to the same host and access the remote filesystem normally. However, Codex Desktop remote SSH cannot complete the authentication flow.
This is a common setup in university/HPC environments where users cannot switch to simple key-only SSH authentication or change the server-side policy.
For this class of remote environment, it would be very helpful if Codex Desktop could either:
support OpenSSH keyboard-interactive/PAM prompts directly, or
delegate connection establishment to the system OpenSSH client so Codex can inherit the same behavior as ssh <host> and VS Code Remote SSH.
At minimum, Codex Desktop should report this as an unsupported keyboard-interactive/PAM authentication flow rather than a generic SSH connection failure. /
Same here, I really need to connect and use Codex on two servers but I have the dynamic hardware tokens to connect and it does not work. Is there any workaround? Right now I am forced to use Cursor, it works there. But the interface is not that good when working on two projects on the same server...
someone look into this?
I am seeing a similar user-facing failure, but my server does not require keyboard-interactive/PAM or MFA. Native Windows OpenSSH authenticates completely using public key only, opens a shell successfully, and Antigravity connects using the same SSH config. Server-side logs show Codex’s public key is accepted, the SSH session opens, and then the Codex client immediately disconnects. I tested both ED25519 and RSA keys with no passphrase. This appears to be a post-authentication remote bootstrap failure rather than an unsupported keyboard-interactive flow. Codex only displays “SSH connection failed” and exposes no detailed client log.
same issue here.
same issue here, claude code supports /remote-control, codex doesn't.