Reduce Log Spam for SSH port forwarding

[programmerq]

Current behavior:

When using tsh ssh -L ..., tsh ssh -R ... or tsh ssh -D ... port forwarding, a connection refused or connection timed out, a full stack trace is logged to the SSH node log.

Expected behavior:

Node logs shouldn't need to print a full-blown stack trace to accompany basic networking issues encountered via port forwarding.

Bug details:

Observed with Teleport 15.4.x, other versions could be affected.

2024-12-16 22:22:13.623 ERRO             Error handling forwarding request for address "detectportal.firefox.com:80". error:[
2024-12-16 22:22:13.623   ERROR REPORT:
2024-12-16 22:22:13.623   Original Error: *net.OpError dial tcp 34.107.221.82:80: connect: connection timed out
2024-12-16 22:22:13.623     Stack Trace:
2024-12-16 22:22:13.623       github.com/gravitational/teleport/lib/srv/reexec.go:629 github.com/gravitational/teleport/lib/srv.handleLocalPortForward
2024-12-16 22:22:13.623       github.com/gravitational/teleport/lib/srv/reexec.go:781 github.com/gravitational/teleport/lib/srv.runForward.func2
2024-12-16 22:22:13.623       runtime/asm_amd64.s:1695 runtime.goexit
2024-12-16 22:22:13.623   User Message: dial tcp 34.107.221.82:80: connect: connection timed out] srv/reexec.go:782
2024-12-16 22:22:16.631 2024-12-16T22:22:16Z INFO [AUDIT]     port addr:detectportal.firefox.com:80 addr.local:127.0.0.1:3080 addr.remote:1.2.3.4:21526 code:T3003I ei:0 event:port login:user success:true time:2024-12-16T22:22:16.556Z uid:56877e9e-2278-52bc-bbce-7cd6a569b8b2 user:user@example.com user_kind:1 events/emitter.go:288

Steps to reproduce:

This could be reproduced with any "connection timed out" scenario in conjunction with tsh ssh port forwarding. This was initially reported with the Firefox portal detection URL, so I've included that as the condition to reproduce.

• On the Teleport Node itself, block the Firefox portal detection URL so it results in a "connection timed out" scenario.
• tsh ssh -D 1080 user@host
• Configure Firefox on your machine running tsh to use the socks proxy at 127.0.0.1:1080

I found that I couldn't get the same stack trace on my 16.4.11 node. The way I blocked the endpoint resulted in a different stack trace because it was a "connection reset by peer" instead of "connection timed out".

sudo ip link add dummy0 type dummy
sudo ip link set dummy0 up
sudo ip route add 34.107.221.82 dev dummy0

Dec 16 16:32:31 myhost teleport[1020624]: 2024-12-16T16:32:31-07:00 WARN             "Connection problem in direct-tcpip channel: \nERROR REPORT:\nOriginal Error: trace.aggregate read unix @->@: read: connection reset by peer\nStack Trace:\n\tgithub.com/gravitational/teleport/lib/utils/proxyconn.go:95 github.com/gravitational/teleport/lib/utils.ProxyConn\n\tgithub.com/gravitational/teleport/lib/srv/regular/sshserver.go:1691 github.com/gravitational/teleport/lib/srv/regular.(*Server).handleDirectTCPIPRequest\n\truntime/asm_amd64.s:1695 runtime.goexit\nUser Message: read unix @->@: read: connection reset by peer *trace.TraceErr." regular/sshserver.go:1692
Dec 16 16:32:31 myhost teleport[1020624]: 2024-12-16T16:32:31-07:00 DEBU [NODE]      Closing direct-tcpip channel from 0.0.0.0:0 to 34.107.221.82:80. id:175 local:192.168.168.191:41708 login:jefferya remote:203.0.113.183:55005 teleportUser:jeff regular/sshserver.go:1712
Dec 16 16:32:31 myhost teleport[1020624]: 2024-12-16T16:32:31-07:00 INFO [AUDIT]     port addr:34.107.221.82:80 addr.local:192.168.168.191:41708 addr.remote:203.0.113.183:55005 code:T3003I ei:0 event:port login:jefferya success:true time:2024-12-16T23:32:31.81Z uid:d3e899e1-9299-8c90-6b2d-a8d5dc1ee1c8 user:jeff user_kind:1 events/emitter.go:288