openssh unix dev - Aug 2020 - Tunneling as a non-root user

I?m setting up a Linux machine (CentOS7) and am trying to allow tap/tun
tunneling.

Our organization?s security policy prohibits root logins.
Using OpenSSH server 7.4 (as provided by the CentOS repositories) non-root users
are able to open tunnels as long as the sshd_config has The setting
UsePrivilegeSeparation=no.

All is well, but I wonder what security risks I am taking by disabling the
separation.

Also, I would like to update to a more current version of the server for
security as well as for the SSH_TUNNEL environment variable introduced in 7.7,
but the UsePrivilegeSeparation option has been deprecated and a current version
(8.3p) refuses to run with that option present in the config file. Removing the
option, the ioctl() to create the tun/tap interface fails, just like with 7.4.

Now that privilege separation is a requirement, is the only way forward to allow
root logins and authorize the client users by copying their public key into
root?s authorized_keys file?

If this is the case, I would be giving up per-user auditing, requiring keys
instead of password (or PAM-based) authentication, as well as the ability to use
Match blocks to control which users/groups/hosts are allowed to create tunnels
and which are allowed normal sessions.

Is this on the roadmap for future consideration?


-Thanks,

 Travis

On Wed, 19 Aug 2020, Travis Hayes wrote:
> I?m setting up a Linux machine (CentOS7) and am trying to allow
> tap/tun tunneling.
>
> Our organization?s security policy prohibits root logins. Using
> OpenSSH server 7.4 (as provided by the CentOS repositories) non-root
> users are able to open tunnels as long as the sshd_config has The
> setting UsePrivilegeSeparation=no.
>
> All is well, but I wonder what security risks I am taking by disabling
> the separation.
>
> Also, I would like to update to a more current version of the server
> for security as well as for the SSH_TUNNEL environment variable
> introduced in 7.7, but the UsePrivilegeSeparation option has been
> deprecated and a current version (8.3p) refuses to run with that
> option present in the config file. Removing the option, the ioctl() to
> create the tun/tap interface fails, just like with 7.4.
>
> Now that privilege separation is a requirement, is the only way
> forward to allow root logins and authorize the client users by copying
> their public key into root?s authorized_keys file?
>
> If this is the case, I would be giving up per-user auditing, requiring
> keys instead of password (or PAM-based) authentication, as well as the
> ability to use Match blocks to control which users/groups/hosts are
> allowed to create tunnels and which are allowed normal sessions.
>
> Is this on the roadmap for future consideration?
tun/tap forwarding has always been a bit of a fringe feature and
has never had reliable non-root support. The problem is essentially
that most of the operations required to configure a network interface
are privileged.

A few people have asked for non-root tun forwarding over the years,
but nobody has come forward with a design for how it could work in
practice.

I'd certainly be open to a design that used some sort of plug-in
helper program to do the configuration steps, and let OpenSSH punt
all the decision-making to that :)

-d

Damien Miller wrote:
> A few people have asked for non-root tun forwarding over the years,
> but nobody has come forward with a design for how it could work in
> practice.
> 
> I'd certainly be open to a design that used some sort of plug-in
> helper program to do the configuration steps, and let OpenSSH punt
> all the decision-making to that :)
Would it be an option to keep the tun/tap code and teach it privsep?


//Peter