[WIP] Support for "permitlisten=..." option for -R style forwarding

[binwiederhier]

I am aware that this is not the right place for patches, but it's makes it easier to review while it's WIP.

Adds support for permitlisten=... for -R style forwarding:

authorized_keys file:

restrict,command="echo 'Port forwarding only account.'",permitlisten="localhost:8080" ssh-rsa AAAAB3Nza...

This is allowed:

ssh -o ExitOnForwardFailure=yes -R 8080:localhost:80 root@localhost -p 2222 -N

This is not:

ssh -o ExitOnForwardFailure=yes -R 8081:localhost:80 root@localhost -p 2222 -N
Error: remote port forwarding failed for listen port 8081

[Jakuje]

This indentation does not match OpenBSD style guide:

Indentation is an 8 character tab. Second level indents are four spaces. All code should fit in 80 columns.

Not only here, but also in other places.

[petiepooo]

Can you specify multiple instances of permitlisten? IOW, could I say

 restrict,command="echo 'Port forwarding only account.'",permitlisten="localhost:8080",permitlisten="localhost:8081" ssh-rsa AAAAB3Nza...

and allow remote connectinos from both 8080 and 8081?

I'm also wondering if this is a useful framework for specifying what local forwards are allowed. Say you had an authorized_keys file containing

 restrict,command="echo 'Port forwarding only account.'",permitforward="10.1.2.3:80" ssh-rsa AAAAB3Nza...

which allowed

 ssh -o ExitOnForwardFailure=yes -L 8080:10.1.2.3:80 root@localhost -p 2222 -N 

but not a different host like

 ssh -o ExitOnForwardFailure=yes -L 8080:192.168.2.3:80 root@localhost -p 2222 -N 

or or a different port like

 ssh -o ExitOnForwardFailure=yes -L 8080:10.1.2.3:8080 root@localhost -p 2222 -N 

Potentially useful but not required would be the ability to wildcard (or omit) the port, or use CIDR notation for the host/net... Just thinking out loud here.

[petiepooo]

Oh.. NM. I dug into the code and I see permitopen does just that. Yay!

[binwiederhier]

Yup, you got that right, it works just like permitopen.

[djmdjm]

permitlisten/PermitListen options shipped in openssh-7.8 (V_7_8) see commits 115063a, 93c06ab and subsequent fixing

[spmfox]

Hello, sorry if this is the wrong place. I've been trying this feature for hours and I think there may be an issue with it. When using (restrict,permitlisten="host:port") in the authorized_keys, it fails with (debug1: Remote: Server has disabled port forwarding.)

If you use 'port-forwarding' and 'permitlisten', it works - and you can try the "wrong" port and it fails as expected. So I know the feature works, but when used with 'restrict' it seems to only work if you also use 'port-forwarding' as well. This is on CentOS 8 (OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS 28 May 2019).

Can anyone point me in the right direction?

[Jakuje]

Do you have UseDNS yes in your sshd_config (assuming the host is hostname and not IP address)?

[spmfox]

@Jakuje yes (its on by default and mine is not defined off), but I tried with using 127.0.0.1 vs localhost and that does not work as well. I actually couldn't get '127.0.0.1' working at all.

What I'd like to work:

restrict,command="echo 'Port forwarding only account.'",permitlisten="localhost:5005"
+
ssh -R 5005:localhost:22 -N
---
Warning: remote port forwarding failed for listen port 5005

How I got it working:

restrict,command="echo 'Port forwarding only account.'",port-forwarding,permitlisten="localhost:5005"
+
ssh -R 5005:localhost:22 -N
---
Works

Sanity check, change the allowed port:

restrict,command="echo 'Port forwarding only account.'",port-forwarding,permitlisten="localhost:6006"
+
ssh -R 5005:localhost:22 -N
---
Warning: remote port forwarding failed for listen port 5005

Here is something else, when the port is wrong and it fails (expected) I see this:

debug1: Remote: port forwarding refused

However, when you remove 'port-fowarding' from the authorized_keys, you see this:

debug1: Remote: Server has disabled port forwarding.

So what that is saying to me is that 'permitlisten' is not overriding the 'restrict' option, as suggested here that it should.

[Jakuje]

@Jakuje yes (its on by default and mine is not defined off)

In both OpenSSH 8.0 and CentOS 8 it defaults to no:

https://github.com/openssh/openssh-portable/blob/V_8_0/sshd_config.5#L1595
https://git.centos.org/rpms/openssh/blob/c8/f/SOURCES (neither of patches changes this)

If you believe there is a bug in the permitlisten implementation (or documentation), open a bug in https://bugzilla.mindrot.org/

[spmfox]

@Jakuje thank you for the reply, I'll try a few more things and I will probably submit a bug.

And yes I was looking at a different (online) version of the man pages that said the default was on - system man pages clearly state the default is off as you suggested so thank you for clarifying.

[spmfox]

Just following up - I found the behavior is exactly the same for 'permitopen', so now I believe it has nothing to do with this feature but rather just how the restrictions work in general. I did file a bug because I believe this causes a gap in the restriction methods. Thanks again for the replies.

https://bugzilla.mindrot.org/show_bug.cgi?id=3159

[binwiederhier]

Now this is really going off topic, but if you are not happy with how openssh restrictions behave, it is incredibly easy to write your own SSH daemon on top of something like the gliderlabs/ssh library. I ended up doing that for my company and it works beautifully on a mega large scale.

It allows much tighter control than openssh does in config -- which is only natural if you're using code instead of config. I'm sure the openssh-library would allow similar things.