Fix repeated "channel N: open failed" SSH chatter (#1957)

[tarun-khatri]

Description

Fixes #1957.

Issue #1957 (open since Oct 2022, no prior PR) reports that channel N: open failed: connect failed: open failed repeatedly appears in the user's terminal during interactive Warp SSH sessions. The wording comes from OpenSSH's channel_input_open_failure() (channels.c:3721), emitted via logit() (INFO level) whenever a client-initiated channel-open is rejected by the server with SSH2_OPEN_CONNECT_FAILED. The most common trigger is a LocalForward configured in the user's ~/.ssh/config whose target the server cannot reach.

The interactive ssh in warp_ssh_helper (defined in bash_body.sh, zsh_body.sh, and fish.sh) ran with OpenSSH's default LogLevel=INFO, so this chatter leaked straight into the Warp PTY. Users could not silence it via ~/.ssh/config because command-line -o wins over config under OpenSSH's first-obtained-value semantics — and Warp wasn't passing one.

This PR passes -o LogLevel=ERROR on the wrapper invocation in all three shell bootstraps. ERROR-level messages (auth failures, host unreachable, fatal protocol errors) continue to surface; only the INFO chatter is suppressed.

Testing

Live repro (without rebuilding Warp)

I drove the failure path end-to-end against a userland sshd to confirm both the bug and the fix. Strategy: spin up sshd on 127.0.0.1:2222, ssh through it with -N -L 9876:127.0.0.1:1 (port 1 unreachable), connect to localhost:9876 to make the client send CHANNEL_OPEN, observe the server's CHANNEL_OPEN_FAILURE(CONNECT_FAILED) come back through channel_input_open_failure() to the client's stderr.

BEFORE — default LogLevel (what reaches the Warp user today):

Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused

AFTER — same scenario with -o LogLevel=ERROR:

(no stderr — silent)

Regression test

Added test_warp_ssh_helper_suppresses_openssh_chatter in app/src/terminal/bootstrap_test.rs. It include_str!s each of the three bundled bootstrap files and asserts the warp_ssh_helper invocation retains -o LogLevel=ERROR, so a future refactor cannot silently regress GH-1957.

Not run locally

cargo nextest run --workspace and ./script/presubmit were not run on the dev box used for this change (it didn't have the full Warp build toolchain installed). The change is confined to (a) three bundled shell scripts loaded as runtime assets and (b) one new self-contained Rust unit test that uses include_str! and &str operations only — no other Rust code paths are touched. CI runs the full presubmit on PR submission. (This mirrors the posture of recently-merged #9388, "Not run: cargo test -p languages because this … host does not currently have cargo installed.")

Server API dependencies

This PR has no server dependencies.

Changelog Entries for Stable

CHANGELOG-BUG-FIX: Suppress spurious channel N: open failed OpenSSH INFO chatter during interactive SSH sessions (GH-1957).

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @tarun-khatri on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@tarun-khatri

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR suppresses INFO-level OpenSSH channel-open-failure chatter in the Warp-managed interactive SSH helper by passing -o LogLevel=ERROR in the bash, zsh, and fish bootstraps, and adds a regression test that checks all three bundled helper invocations retain the option.

Concerns

• No blocking correctness concerns found in the changed lines.
• Supplemental security pass found no new security concerns; the change only lowers OpenSSH client log verbosity for this managed interactive invocation and keeps ERROR-level failures visible.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[tarun-khatri]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!