bugzilla-daemon at mindrot.org
2005-Mar-05 12:01 UTC
[Bug 993] adding and removing forwardings via the control connection
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 at mindrot.org ReportedBy: torsten.foertsch at 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.
bugzilla-daemon at mindrot.org
2005-Mar-05 12:04 UTC
[Bug 993] adding and removing forwardings via the control connection
http://bugzilla.mindrot.org/show_bug.cgi?id=993 ------- Additional Comments From torsten.foertsch at gmx.net 2005-03-05 23:04 ------- Created an attachment (id=847) --> (http://bugzilla.mindrot.org/attachment.cgi?id=847&action=view) -O add-rforward -O cancel-rforward ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2005-Mar-05 12:05 UTC
[Bug 993] adding and removing forwardings via the control connection
http://bugzilla.mindrot.org/show_bug.cgi?id=993 ------- Additional Comments From torsten.foertsch at gmx.net 2005-03-05 23:05 ------- (From update of attachment 847) the patch is against openssh-SNAP-20050302 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.