Suppressing reverse port-forward connection errors

[Damien Miller]

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...

-d