Bug 2038 - permitopen functionality but for remote forwards
Summary: permitopen functionality but for remote forwards
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 6.0p1
Hardware: Other Other
: P5 enhancement
Assignee: Damien Miller
URL:
Keywords:
: 2751 2842 (view as bug list)
Depends on:
Blocks: V_7_8
  Show dependency treegraph
 
Reported: 2012-08-29 12:05 AEST by proctor
Modified: 2021-04-23 14:58 AEST (History)
20 users (show)

See Also:


Attachments
[PATCH] 6.6p1-permitremoteopen (13.64 KB, patch)
2014-05-15 17:25 AEST, Atony Antony
no flags Details | Diff
tested on 6.7p1 and applies on cvs current too. (13.98 KB, patch)
2014-12-16 11:54 AEDT, Atony Antony
no flags Details | Diff
7.5p1 permitremoteopen patch (12.63 KB, patch)
2017-09-19 21:16 AEST, Atony Antony
no flags Details | Diff
PermitRemoteOpen directive (34.02 KB, patch)
2018-05-22 10:11 AEST, Damien Miller
no flags Details | Diff
parse authorized_keys option permitremoteopen="port" (4.86 KB, application/octet-stream)
2018-05-22 20:15 AEST, Atony Antony
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description proctor 2012-08-29 12:05:53 AEST
i have a very similar use case to bug 1949 where i would like to create a reverse ssh box using:

ssh login@box -R 2000:localhost:22

however i would like to be able to specify on the remote server what port/s are able to be forwarded back to the client e.g. only 2000 in this case. this might be accomplished in the same way that permitOpen is used to limit the local forwards allowable on the server: in the sshd_config and/or in the authorized_keys file.

in my case the remote server would be a backup machine that allows remote backups from the field, even from behind firewalls, but trusting the client the least amount possible. in the server configuration all the client would be allowed to do is connect to the server and forward a predetermined (set of) port/s back to itself, by which the server could then initiate a remote backup.


sincerely,
proctor
Comment 1 Damien Miller 2012-09-07 12:11:58 AEST
Some options:

1. Separate option

PermitROpen 2000 2001 2002 3000-3999

2. Reuse PermitOpen, but treat numbers without ':' as -R port numbers

PermitOpen 127.0.0.1:1234 2000 2001 2002 3000-3999

The advantage of (1) is that we can extend it to allow selection of bind address, but (2) can't do this...
Comment 2 proctor 2012-09-08 16:47:41 AEST
(In reply to comment #1)
> Some options:
> 
> 1. Separate option
> 
> PermitROpen 2000 2001 2002 3000-3999
> 
> 2. Reuse PermitOpen, but treat numbers without ':' as -R port numbers
> 
> PermitOpen 127.0.0.1:1234 2000 2001 2002 3000-3999
> 
> The advantage of (1) is that we can extend it to allow selection of
> bind address, but (2) can't do this...

from my point of view either one of these solutions would be _very_ welcome. although i don't require it at this moment, i can certainly imagine scenarios where control over bind address would be valuable. are there any drawbacks to option one?

sincerely,
proctor
Comment 3 Atony Antony 2014-05-15 17:25:58 AEST
Created attachment 2436 [details]
[PATCH] 6.6p1-permitremoteopen

I have been wokring on a similar idea. See the attached patch. It works on Linux (6.6p1). It also seems to apply on OpenBSD version 6.4,6.5.
https://github.com/antonyantony/openssh/
Comment 4 james 2014-06-20 01:03:45 AEST
This patch seems exactly what I need (I had just posted a message to -devs and had started to investigate writing my own patch).

I will apply and verify that it works for me (I would want to specify the restricted port on a per-user basis)
Comment 5 Atony Antony 2014-12-16 11:54:51 AEDT
Created attachment 2517 [details]
tested on 6.7p1 and applies on cvs current too.
Comment 6 james 2014-12-17 08:16:07 AEDT
What needs to happen to get this patch into master? I have been using this and it seems a sensible, low risk addition
Comment 7 Marcus Popp 2015-02-02 22:57:13 AEDT
*** Bug 2347 has been marked as a duplicate of this bug. ***
Comment 8 Martin Häcker 2015-05-12 02:20:37 AEST
I would like to add that we identified a possible security risk by not being able to restrict the remote port forwarding.

Our use case is that we want to give one customer the ability to safely (via ssh tunnel) access a service that is only accessible locally on a machine, but noticed that if we allow him to locally (-L) forward a port, he can also use ssh to bind to any other port via -R.

The problem with this is that ssh by default is perfectly happy to bind to ipv6 addresses, even for ports where the ipv4 address is already bound (8080 for some web server for example).

Now other more modern tools (e.g. apache) could try to connect to the newly opened ipv6 port instead of the original service, if they are configured to use symbolic names like 'localhost'

I don't think this is a big risk, but certainly very unexpected for us.
Comment 9 Jean-Noel COUERON 2016-11-04 03:24:36 AEDT
Please add this feature that's exactly what i need.

sincerely

Jean-Noel
Comment 10 ernst 2016-12-28 05:40:27 AEDT
This would also be highly beneficial for the local setup here.

PermitOpen supports local portforward restrictions, but remote PFs cannot be restricted in vanialla OpenSSH at the moment.

Please incorporate patch for restricting *remote* port forwards as well. 

Currently have to do this the clunky way using SELinux or similar to restrict which users may listen on which ports.
Comment 11 rgm 2017-06-24 01:57:25 AEST
I'd love this functionality, please consider for inclusion in OpenSSH 7.6.  Is there something different or additional you'd like to see in the patch before you'll include it?
Comment 12 ernst 2017-06-24 02:31:28 AEST
Greetings, I can also only re-affirm the usefulness of such a restriction possibility.

Primary concern here is restriction on which listen ports the client can bind to.
Comment 13 Atony Antony 2017-09-19 21:16:43 AEST
Created attachment 3054 [details]
7.5p1 permitremoteopen patch

up request to update the here is one for 7.5p1 If you need a patch for CentOS 7.3+ drop me a line.
Comment 14 Cody Edwards 2018-02-01 08:11:13 AEDT
Are there plans to merge the patch (https://github.com/antonyantony/openssh/) back into openssh?

I did not find a open or closed pull request with this patch in https://github.com/openssh/openssh-portable
Comment 15 ernst 2018-02-02 00:13:21 AEDT
Not sure why the maintainers let a security-enhancing small patch rot here for several years.
Comment 16 Martin Häcker 2018-02-02 01:39:02 AEDT
Maybe they need all he energy they have to move to a better integrated issue tracker and code hosting service that also tracks pull requests as a first class object?
Comment 17 bolt 2018-03-22 05:30:34 AEDT
*** Bug 2842 has been marked as a duplicate of this bug. ***
Comment 18 bolt 2018-03-22 05:31:40 AEDT
I have this exact same use case in the duped bug. Please integrate?
Comment 19 william.martin 2018-03-23 05:24:53 AEDT
I have the same request too. Can you merge the patch ?
Comment 20 ms.huan.zhao 2018-04-13 12:05:19 AEST
Sadly to see almost 6 years past without final decision. But I'm still looking forwarding to having the feature to close the security loophole in my case.
Comment 21 Damien Miller 2018-05-22 10:11:41 AEST
Created attachment 3152 [details]
PermitRemoteOpen directive

This is an implementation of PermitRemoteOpen, including regress tests and a small refactoring of the permitopen permissions to enable more sharing of code.

TODO: authorized_keys permitremoteopen, PermitRemoteOpen="123" (i.e. bare port number), manual pages.
Comment 22 Atony Antony 2018-05-22 20:15:41 AEST
Created attachment 3153 [details]
parse authorized_keys option permitremoteopen="port"

this is great. my first attempt to add parsing authrorized_keys permitremote="port"option. 

It is also updated at https://github.com/antonyantony/openssh
thanks.
Comment 23 Atony Antony 2018-05-22 21:44:21 AEST
I just found out that my patch incomplete. it need more work.
Comment 24 Damien Miller 2018-05-25 13:34:43 AEST
*** Bug 2751 has been marked as a duplicate of this bug. ***
Comment 25 Damien Miller 2018-06-07 04:37:57 AEST
I've committed a variant of the patch that names the directive PermitListen and added a permitlisten directive for authorized_keys. This will be in the OpenSSH 7.8 release, due within the next few months.
Comment 26 Martin Häcker 2018-06-07 16:16:00 AEST
🎉
Comment 27 Damien Miller 2018-06-19 13:03:29 AEST
... and I just added support for bare port numbers in permitlisten/PermitListen:

commit 80e199d6175904152aafc5c297096c3e18297691 (HEAD -> master)
Author: djm@openbsd.org <djm@openbsd.org>
Date:   Tue Jun 19 03:02:17 2018 +0000

    upstream: test PermitListen with bare port numbers
    
    OpenBSD-Regress-ID: 4b50a02dfb0ccaca08247f3877c444126ba901b3

commit 87ddd676da0f3abd08b778b12b53b91b670dc93c
Author: djm@openbsd.org <djm@openbsd.org>
Date:   Tue Jun 19 02:59:41 2018 +0000

    upstream: allow bare port numbers to appear in PermitListen directives,
    
    e.g.
    
    PermitListen 2222 8080
    
    is equivalent to:
    
    PermitListen *:2222 *:8080
    
    Some bonus manpage improvements, mostly from markus@
    
    "looks fine" markus@
    
    OpenBSD-Commit-ID: 6546b0cc5aab7f53d65ad0a348ca0ae591d6dd24
Comment 28 Taylor R 2019-03-05 07:33:03 AEDT
Now if only -R0 would pull from these ports specified in PermitListen.
PermitListen is halfway to what I'm looking to do. Attempting to brush up on my C enough to craft a solution in the source files.
Comment 29 Damien Miller 2021-04-23 14:58:50 AEST
closing resolved bugs as of 8.6p1 release