Bug 3159 - authorized_keys: gap in port forwarding restrictions
Summary: authorized_keys: gap in port forwarding restrictions
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.0p1
Hardware: Other Linux
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-06 04:45 AEST by spmfox
Modified: 2020-05-06 04:48 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description spmfox 2020-05-06 04:45:30 AEST
I believe I have found a gap in the implementation of the port forwarding restrictions. I've been testing this on CentOS Linux release 8.1.1911 + OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS  28 May 2019.

Currently we have the following options to restrict port forwarding in the authorized_keys file:

---
restrict: Enable all restrictions
no-port-forwarding: Forbids TCP forwarding when this key is used for authentication.
port-forwarding: Enable port forwarding previously disabled by the restrict option.
permitopen: Limit local port forwarding with the ssh(1) -L option such that it may only connect to the specified host and port.
permitlisten: Limit remote port forwarding with the ssh(1) -R option such that it may only listen on the specified host (optional) and port.
---

If you enable 'restrict' or 'no-port-forwarding', it does not matter if you also use 'permitopen' or 'permitlisten' - all port forwarding requests are still denied. Assuming 'restrict' is in use, if you want to enable port forwarding you must also use 'port-forwarding'. At this point, all port forwarding (local and remote) are allowed.

Assume you only want one remote port allowed, "localhost:5000". If you use 'permitlisten=localhost:5000', you will restrict all other remote ports from being opened - only allowing that one. However you leave the local port forwarding wide open.

There is no easy way to lock down both local and remote port forwarding, if you are using one and not the other, since they cannot be disabled/enabled individually.

=================
Examples:
(restrict,command="echo 'Port forwarding only account.'",permitlisten="localhost:5000")
Logically, this looks like we've enabled every restriction, then allowed one remote port forward. This will *not* work at all, since 'port-forwarding' isn't specified.
===
(restrict,command="echo 'Port forwarding only account.'",port-forwarding,permitlisten="localhost:5000")
Now we've enabled port forwarding, and it looks like we've locked it down to one remote port. This will work, however *local port forwarding is wide open* - in fact, this will even allow unrestricted dynamic port forwarding as well.
===
(restrict,command="echo 'Port forwarding only account.'",port-forwarding,permitlisten="localhost:5000",permitopen:"localhost:22")
This is the only way I found to restrict local AND remote forwarding, when you only really want to use remote. Assuming local port 22 is already exposed (since you're connecting to it) we can specify that port and that will block all other requests.
=================

My personal opinion is: Keep 'restrict', 'no-port-forwarding', and 'port-forwarding' the same, however when you use 'permitlisten or 'permitopen' its automatically exempt from 'restrict' or 'no-port-forwarding'. This would allow you to do a blanket restriction, and then open local or remote ports as-needed while still giving the option to block or also allow all ports local or remote.