Suppressing reverse port-forward connection errors

[Joe K]

On Fri, Dec 5, 2025 at 7:40 PM Damien Miller <djm at mindrot.org> wrote:
>
> On Fri, 5 Dec 2025, Joe K wrote:
>
> > > We have LogVerbose that turns up detailed logging; maybe we could do a
> > > LogSuppress that does the opposite?
> > >
> > > Alternately, you could run ssh in multiplexing mode and separate the
> > > control process (which will get error reports) from the session process
> > > (which shouldn't). Perhaps even running with ControlPersist would be
> > > sufficient here...
> >
> > After some more testing I think I figured out what my original issue
> > was. I am sending the client a keyboard-interactive info request with
> > text (a sign-in url) in the instruction field, and no prompts. If I
> > start ssh with -q or -y, the name and instruction messages end up
> > being suppressed or written to syslog, respectively. It looks like the
> > prompt strings in the info request (and also standard password
> > prompts) _are_ written to the tty even when -q or -y is given, but the
> > name and instruction fields are printed as regular logs at info level.
> >
> > If this can be changed so that the name/instruction fields of
> > keyboard-interactive info requests are printed to the tty as well,
> > then using -q/-y would be sufficient for my use case as-is.
> > Multiplexing mode does work here too - though if the control process
> > is backgrounded, it is useful to also start it with -y to preserve its
> > output in syslog. I think such a change would also be in line with the
> > examples given in RFC4256.
> >
> > What do you think? I'd be happy to send a patch if you are open to it.
>
> oh yeah, information essential to authentication shouldn't be hidden
> by -q or sent to syslog with -y, so the current behaviour is a bug
> that should be fixed.
>
> Is sending it to stderr enough, or does it need to go directly to
> the tty? If the latter, then we should probably have a function for
> doing that.

Since the info request message has several configurations
(with/without name or instruction, 0/1/>1 prompts), perhaps the ideal
UX for each depends on whether or not an askpass tool is to be used.
In a terminal, the current behavior of showing the name/instruction
once, then following up with each prompt is correct. A graphical
askpass tool might only be able to show one prompt/input at a time,
and since the instruction could be relevant for each prompt, we might
want to prepend the instruction string to each prompt string before
they are displayed. But unconditionally prepending the instruction to
the prompt would be awkward in a terminal if there are multiple
prompts.

The case of instruction + no prompt is unique; currently openssh will
not invoke askpass at all unless there is at least one prompt, which
means in some gui-only ssh frontends (e.g. vscode remote workspace)
the only way to see the instructions is if the frontend provides a way
to view the ssh logs, and if you know to look for them. Maybe this
case could be handled by a non-text-input askpass prompt like the ones
used with some of the multiplexing commands?

Joe