wezterm/wezterm · error

unhandled auth case; methods={:?}, status={:?}

Error message

unhandled auth case; methods={:?}, status={:?}

What it means

This is the terminal bail of wezterm's libssh auth loop: after trying publickey (agent auto), keyboard-interactive, and password, none returned Success/Partial, so the loop falls through and reports which methods the server offered plus the statuses recorded per method. It means the server's offered authentication methods and wezterm/libssh's capabilities did not intersect successfully.

Source

Thrown at wezterm-ssh/src/auth.rs:247

                            echo: false,
                        }],
                        reply,
                    }))
                    .unwrap();

                let mut answers = smol::block_on(answers.recv())
                    .context("waiting for authentication answers from user")
                    .unwrap();
                let pw = answers.remove(0);

                match sess.userauth_password(None, Some(&pw))? {
                    AuthStatus::Success => return Ok(()),
                    AuthStatus::Partial => continue,
                    status => anyhow::bail!("password auth status: {:?}", status),
                }
            }

            anyhow::bail!(
                "unhandled auth case; methods={:?}, status={:?}",
                auth_methods,
                status_by_method
            );
        }
    }

    #[cfg(feature = "ssh2")]
    pub fn authenticate(
        &mut self,
        sess: &ssh2::Session,
        user: &str,
        host: &str,
    ) -> anyhow::Result<()> {
        use std::collections::HashSet;

        loop {
            if sess.authenticated() {

View on GitHub (pinned to 3ff7522b96)

Solutions

1. Load a key the server accepts into ssh-agent (ssh-add) and confirm wezterm can see SSH_AUTH_SOCK, so userauth_public_key_auto succeeds
2. Check the methods=... part of the message: if it lists only methods wezterm doesn't do (hostbased, gssapi-with-mic), enable password or keyboard-interactive on the server or use a Kerberos-capable client
3. Verify the key file permissions and that the public key is in the server's authorized_keys
4. As a workaround, shell out: use wezterm's default domain with the system `ssh` binary instead of a wezterm ssh_domain

Example fix

-- before: wezterm ssh_domain without usable keys
-- after: let the OS ssh handle exotic auth
config.terminals = nil
-- spawn the system ssh instead of an ssh_domain:
-- wezterm.spawn_command... default: 'ssh host' via the local domain

# before relying on a wezterm ssh_domain, confirm the server offers a method you can satisfy
ssh -v user@host 2>&1 | grep -i 'authentications that can continue'

On SessionEvent::Error containing 'unhandled auth case', guide the user to load keys into ssh-agent or use the system ssh client instead of retrying the domain.

When it happens

Trigger: Session::authenticate_libssh where userauth_list returns only methods wezterm cannot satisfy — e.g. 'publickey' with no usable key in the agent, or 'hostbased'/'gssapi-with-mic' which wezterm never attempts — and the password/interactive arms are absent because the server didn't advertise them, or were tried and recorded a non-success status in status_by_method.

Common situations: Server configured with only publickey auth while the user has no agent/key loaded in the wezterm session; sites requiring GSSAPI/Kerberos; expired or non-existent default identity keys; agent (e.g. 1Password/ssh-agent socket) not visible to wezterm.

Related errors

• unable to authenticate session
• interactive auth status: {:?}
• password auth status: {:?}
• Authentication was cancelled
• user cancelled authentication

AI-assisted analysis of wezterm/wezterm@3ff7522b96 (2026-08-20). Data as JSON: /api/errors/df528089f98d367f. Report an issue: GitHub.