Suppressing reverse port-forward connection errors

[Damien Miller]

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.

-d