Is support being removed for ordinary users to run sshd?

[Darren Tucker]

On Tue, Mar 28, 2017 at 2:23 AM, Jack Dodds <brmdamon at hushmail.com> wrote:

> Hello Darren,
>
> Could you comment on this issue being raised by myself and
> Corinna Vinschen?
>
> This will create big problems for me.
>
> I'm not clear if this is a conscious decision supported by solid
> reasons or if it is just collateral damage.
>
> Thank you for all you work!
>
> Jack DoDDs
>
> -------- Original Message --------
> Date: Mon, 27 Mar 2017 16:31:03 +0200
> Subject: Re: Announce: OpenSSH 7.5 released
> From: Corinna Vinschen <vinschen at redhat.com>
> To: openssh-unix-dev at mindrot.org
>
> On Mar 24 12:38, Jack Dodds wrote:
> > Hello,
> >
> > You seem to be saying that in 7.5, sshd can no longer be run
> > under an ordinary user account. Is that accurate?
>
> Well, yes, that's what the report claims, and it seems correct to
> me.
>

It's not quite accurate.  The issue is that it checks for the existence of
the privsep user and directory even though it does not use them.  If they
exist (even if only because you configure'ed --with-privsep-user and
--with-privsep-dir to point to other existing ones) then it'll work.  This
is what we use for the regression tests when SUDO is not set (but because
all our test systems have the user and dir, we never observed the problem).


> > I use sshd running under a user account in Debian Jessie to allow
> > tunnels from remote devices. That capability is crucial to my
> > application.
> >
> > Any comments would be appreciated.
>
> Same here.
>
> Is it really just a bug or is the "non-priv'ed user running sshd"
> scenario going to be unsupported in future?
>

My opinion:
 - running as a non-privileged user should be supported.
 - running with privsep disabled (ie one unprivileged process) will not be
supported.

This will mean that you'll have two sshd processes per connection running
as an unprivileged user, same as you would for a privileged user.

Rationale: we want to reduce the code complexity by removing the !privsep
code paths, and some privilege dropping mechanisms like OpenSBD's pledge
can still be employed by unprivileged code).

I've just committed a variation on the patch to both HEAD and the 7.5
branch.

https://anongit.mindrot.org/openssh.git/commit/?id=d13281f2964abc5f2e535e1613c77fc61b0c53e7

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.