Bug 1943 - [PATCH] ssh -W opens two connections when ControlPersist is enabled.
Summary: [PATCH] ssh -W opens two connections when ControlPersist is enabled.
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 5.9p1
Hardware: All All
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_6_0
  Show dependency treegraph
 
Reported: 2011-10-17 04:33 AEDT by Ricky Zhou
Modified: 2023-01-13 13:36 AEDT (History)
2 users (show)

See Also:


Attachments
bz1943.diff (2.29 KB, patch)
2011-10-21 10:45 AEDT, Damien Miller
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ricky Zhou 2011-10-17 04:33:47 AEDT
As reported earlier at

https://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029441.html

there is some strange interaction between ControlPersist and ssh -W that
breaks things if you're using both.  Specifically, ssh -W host:port with
ControlPersist enabled opens up two connections to host:port and sends
data from both back.

I think this is happening because channel_connect_stdio_fwd is being
called twice, once in client_setup_stdio_fwd, which is called from
ssh_init_forwarding, and once in process_mux_stdio_fwd, which is
called once the client process starts talking to the master process.

It looks like the way ControlPersist is implemented, the process forks,
with the child becoming the master process and the child making its
connection through that.   This patch makes client_setup_stdio_fwd not
get called the first time if need_controlpersist_detach is set, and lets
it happen through the master process.
Comment 1 Damien Miller 2011-10-21 10:45:20 AEDT
Created attachment 2100 [details]
bz1943.diff

fix dupe stdio forward with ControlPersist
Comment 2 Damien Miller 2011-11-04 10:14:01 AEDT
patch applied - this will be in openssh-6.0. Thanks!
Comment 3 Simon Sapin 2012-01-07 19:07:50 AEDT
A workaround for versions before 6.0: instead of

    ssh -W %h:%p gateway

Use:

    sh -c "ssh gateway true < /dev/null && ssh -W %h:%p gateway"

The first ssh call does not use -W so it is not affected by this bug. It makes sure that the master process is running. The second call does not need to fork a master so it is not affected either.
Comment 4 Damien Miller 2015-08-11 23:05:54 AEST
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1