Bug 7300 - SSH process fills client logfile when there is a broken port forwarding connection
Summary: SSH process fills client logfile when there is a broken port forwarding conne...
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Pierre Ossman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-27 12:42 CET by Henrik Andersson
Modified: 2021-06-30 09:10 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:

Attachments
Cancel port forwarding if service process is gone (9.89 KB, patch)
2018-12-27 12:46 CET, Henrik Andersson 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Description Henrik Andersson cendio 2018-12-27 12:42:16 CET 
When the client connects a few service processes are running, pulseaudio,
unfsd etc. These services are used from within the session via remote port
forwarding tunnels within the ssh connection.

If a service dies, eg. there is no end point of the remote port forwarding
tunnel and that the server side tries to connect, the SSH process logs an
error message of a broken port forwarding tunnel.

If the client on the server side misbehaves, eg. retries to establish a connection within a loop, the logfile will be filled up.

A simple way to reproduce is:

 1. Connect to a session
 2. Kill pulseaudio process that the client has started
 3. Look at tlclient.log file filling up with error logs from SSH
Comment 2 Henrik Andersson cendio 2018-12-27 12:44:12 CET 
One way to overcome this problem is to cancel the SSH port forwarding
when the client notices that the process behind the service is not
available any more.
Comment 3 Henrik Andersson cendio 2018-12-27 12:46:56 CET 
Created attachment 901 [details]
Cancel port forwarding if service process is gone

This patch will wrap a service process into a subclass that can act upon
when a process is not available anymore. When that is the case, the remote port forwarding will be cancelled.
Comment 4 Henrik Andersson cendio 2018-12-27 13:56:21 CET 
(In reply to comment #3)
> Created an attachment (id=901) [details]
> Cancel port forwarding if service process is gone
> 
> This patch will wrap a service process into a subclass that can act upon
> when a process is not available anymore. When that is the case, the remote port
> forwarding will be cancelled.
>

This patch forces SSH to enable a pseudo tty and uses escape sequence '~C' to
send command '-KR<port>' to cancel an active remote port forwarding.
Comment 5 Pierre Ossman cendio 2019-01-09 13:22:16 CET 
This is a problem when the log level is turned up as you get a whole bunch of debug lines from ssh in that case.

> 2019-01-09T13:20:37: ssh[E]: debug1: client_input_channel_open: ctype forwarded-tcpip rchan 11 win 2097152 max 32768
> 2019-01-09T13:20:37: ssh[E]: debug1: client_request_forwarded_tcpip: listen localhost port 5015, originator 127.0.0.1 port 42828
> 2019-01-09T13:20:37: ssh[E]: debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:34745) in progress, fd=8
> 2019-01-09T13:20:37: ssh[E]: debug1: channel 3: new [127.0.0.1]
> 2019-01-09T13:20:37: ssh[E]: debug1: confirm forwarded-tcpip
> 2019-01-09T13:20:37: ssh[E]: debug1: channel 3: connection failed: Connection refused
> 2019-01-09T13:20:37: ssh[E]: connect_to 127.0.0.1 port 34745: failed.
> 2019-01-09T13:20:37: ssh[E]: debug1: channel 3: free: 127.0.0.1, nchannels 4

On the default level you get the same line each time:

> 2019-01-09T13:20:37: ssh[E]: connect_to 127.0.0.1 port 34745: failed.

Which means it will only be written once (eventually followed by "Last line repeated X times...").
Comment 6 Pierre Ossman cendio 2019-08-13 11:01:03 CEST 
Unfortunately sshd also logs this on the server, filling up server log files. :/

Even if we fix our client to be more well behaved, a malicious client could still use this to fill up the server's log space. Upstream should probably reconsider this logging.
Note You need to log in before you can comment on or make changes to this bug.