You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
Current behavior:
When using
tsh ssh -L ...
,tsh ssh -R ...
ortsh 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.
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.tsh ssh -D 1080 user@host
tsh
to use the socks proxy at 127.0.0.1:1080I 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".
The text was updated successfully, but these errors were encountered: