http://bugzilla.mindrot.org/show_bug.cgi?id=993
Summary: adding and removing forwardings via the control
connection
Product: Portable OpenSSH
Version: 4.0p1
Platform: All
OS/Version: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-bugs@mindrot.org
ReportedBy: torsten.foertsch@gmx.net
Hi,
the attached patch implements adding and canceling of remote port
forwardings by communicating with a running ssh client via a control
socket.
Thus, one can do this:
ssh -MNfS ~/.ssh/ctl remotehost
and then:
ssh -S ~/.ssh/ctl -O add-rforward 2000:forward:80 localhost
to add a new remote forwarding or
ssh -S ~/.ssh/ctl -O cancel-rforward localhost:2000 localhost
to remove it.
The patch is against openssh-SNAP-20050302 so the new fine tuned
forwarding code is already contained.
While working on the patch a few questions/inconveniences have emerged:
1) why is mux_command in ssh.c not part of Options?
2) the current implementation allows -O to occur only once. So, to add
or remove multiple channels ssh has to be called multiple times. Would
it make sense to extend the code to allow it to occur multiple times?
ssh -S ~/.ssh/ctl \
-O add-rforward 2000:forward:80 \
-O add-rforward 2001:forward:80 \
localhost
3) permitted_opens in channels.c is a real problem. The current code
allocates a new element from the end of this array while adding a new
forwarding. But when the forwarding is cancelled the element is not
really freed. It is marked somehow to be not in use but the current
code cannot reuse it.
4) again permitted_opens. channel_request_rforward_cancel() identifies
the local side of a forwarding only by
permitted_opens[i].host_to_connect and permitted_opens[i].listen_port.
Since a forwarding is really a quadruple this looks a little fragile to
me. In fact you can try to remove a forwarding by specifying only a
port number
ssh -S ~/.ssh/ctl -O cancel-rforward 2000 localhost
This matches an element of permitted_opens and resets it but it does not
match an open channel at the server side. So the listening socket is
not closed. Now when someone tries to connect to that port the server
forwards the connection to the client. Here it does not match an
element of permitted_opens. Hence
WARNING: Server requests forwarding for unknown listen_port 2000
is printed and the connection is closed.
I have not yet changed this behaviour because it is the same code that
is used when adding or canceling forwardings with the ssh command line
("~C", then "-R2000:forward:80", then "~C", then "-KR2000" yields the
same result). But I think it's rather a bug than a feature.
Doesn't it make more sense to represent forwardings as quadruples
(remotehost, remoteport, localhost, localport) also at the client side?
5) I think I have to implement -O add-lforward and -O cancel-lforward,
too.
6) Also -O list-forwards would be useful, wouldn't it?
Torsten
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Summary: adding and removing forwardings via the control
connection
Product: Portable OpenSSH
Version: 4.0p1
Platform: All
OS/Version: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-bugs@mindrot.org
ReportedBy: torsten.foertsch@gmx.net
Hi,
the attached patch implements adding and canceling of remote port
forwardings by communicating with a running ssh client via a control
socket.
Thus, one can do this:
ssh -MNfS ~/.ssh/ctl remotehost
and then:
ssh -S ~/.ssh/ctl -O add-rforward 2000:forward:80 localhost
to add a new remote forwarding or
ssh -S ~/.ssh/ctl -O cancel-rforward localhost:2000 localhost
to remove it.
The patch is against openssh-SNAP-20050302 so the new fine tuned
forwarding code is already contained.
While working on the patch a few questions/inconveniences have emerged:
1) why is mux_command in ssh.c not part of Options?
2) the current implementation allows -O to occur only once. So, to add
or remove multiple channels ssh has to be called multiple times. Would
it make sense to extend the code to allow it to occur multiple times?
ssh -S ~/.ssh/ctl \
-O add-rforward 2000:forward:80 \
-O add-rforward 2001:forward:80 \
localhost
3) permitted_opens in channels.c is a real problem. The current code
allocates a new element from the end of this array while adding a new
forwarding. But when the forwarding is cancelled the element is not
really freed. It is marked somehow to be not in use but the current
code cannot reuse it.
4) again permitted_opens. channel_request_rforward_cancel() identifies
the local side of a forwarding only by
permitted_opens[i].host_to_connect and permitted_opens[i].listen_port.
Since a forwarding is really a quadruple this looks a little fragile to
me. In fact you can try to remove a forwarding by specifying only a
port number
ssh -S ~/.ssh/ctl -O cancel-rforward 2000 localhost
This matches an element of permitted_opens and resets it but it does not
match an open channel at the server side. So the listening socket is
not closed. Now when someone tries to connect to that port the server
forwards the connection to the client. Here it does not match an
element of permitted_opens. Hence
WARNING: Server requests forwarding for unknown listen_port 2000
is printed and the connection is closed.
I have not yet changed this behaviour because it is the same code that
is used when adding or canceling forwardings with the ssh command line
("~C", then "-R2000:forward:80", then "~C", then "-KR2000" yields the
same result). But I think it's rather a bug than a feature.
Doesn't it make more sense to represent forwardings as quadruples
(remotehost, remoteport, localhost, localport) also at the client side?
5) I think I have to implement -O add-lforward and -O cancel-lforward,
too.
6) Also -O list-forwards would be useful, wouldn't it?
Torsten
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.