Skip to content

vk-agent: send a command's stderr on the SSH extended-data channel - #6

Open
shelleu-wallix wants to merge 2 commits into
virtkit-dev:mainfrom
shelleu-wallix:fix/ssh-exec-stderr-extended-data
Open

shelleu-wallix wants to merge 2 commits into
virtkit-dev:mainfrom
shelleu-wallix:fix/ssh-exec-stderr-extended-data

Conversation

@shelleu-wallix

Copy link
Copy Markdown
Contributor

A command run over SSH had its stdout and stderr merged onto the channel's data stream. Text output survives that; a framed binary protocol does not — Zed's remote editing hangs at "Starting proxy..." on the first line its proxy logs to stderr. stderr now goes on extended-data type 1, as sshd does. The second commit exports SHELL, missing for the same reason: vk-agent's environment is PID 1's.

New test drives a russh client against the server and fails if the fix is reverted. Workspace green: 1774 tests, clippy, fmt.

Give a command run over SSH a stream per output: stdout on the channel's
data stream, stderr on extended-data type 1, which RFC 4254 reserves for
it. Merged onto one stream as they were, a client reading a framed
protocol off stdout desynchronized on the first line the command logged,
and plain text output hid the problem.

Split the channel rather than consume it into a single stream: the two
writers share its flow-control window, and the halves carry no
close-on-drop that could close the channel ahead of the exit status.
Set SHELL from the passwd entry, as sshd does; vk-agent's own environment
is PID 1's and carries none, so scripts that read it — an editor's remote
bootstrap among them — fell back to sh. The login-shell fallback each of
the three spawn paths spelled out moves into a helper they now share with
the session environment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant