Suppressing reverse port-forward connection errors

[Joe K]

On Thu, Dec 4, 2025 at 9:00 PM Damien Miller <djm at mindrot.org> wrote:
>
> On Wed, 3 Dec 2025, Joe K wrote:
>
> > Hi,
> >
> > I have a use case where I am using reverse port-forwarding with the openssh
> > client, and the server is set up to perform active health checks on some
> > local ports through the tunnel by opening and closing a TCP connection. It
> > works fine, except that if a tunneled connection fails, openssh will print
> > a log to stderr which can clobber an interactive session and necessitate
> > resizing the terminal or something else to force a redraw of the screen.
> >
> > These errors can be suppressed using -q (or -y to move them to syslog), but
> > that also has the side effect of suppressing user-facing messages, such as
> > auth prompts, which is undesirable.
> >
> > I'm wondering if it might make sense to allow some degree of customization
> > on the severity of a failed connection log. In my health checking scenario,
> > a failed connection is an acceptable outcome, but of course this is not
> > always the case. Would it make sense to log connection failures at debug1
> > level (or as errors in syslog only) under some circumstances e.g. if an
> > interactive session is present? Or a client config option or command-line
> > flag?
> >
> > Alternatively, maybe the issue is more so that -q/-y suppresses too much,
> > and ssh should still print some messages to a tty (if one is present) if
> > they are intended for user interaction.
>
> 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.

Joe