Is support being removed for ordinary users to run sshd?

Jack Dodds

unread,

Mar 27, 2017, 11:24:37 AM3/27/17

to Darren Tucker, openssh-unix-dev, Corinna Vinschen

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 <vins...@redhat.com>
To: openssh-...@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.

> 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?

Corinna

> Corinna Vinschen wrote:
> > ----- Forwarded message from Lionel Fourquaux -----
> > > * This release deprecates the sshd_config UsePrivilegeSeparation
> > > option, thereby making privilege separation mandatory.
> >
> > This has (probably not wholly intended) consequences when
> > running sshd in single user (non root) mode:
> >
> > $ /usr/sbin/sshd -D -f ~/.ssh/sshd_config
> > Privilege separation user sshd does not exist
> >
> > The problem is not limited to Cygwin, but is unlikely to happen
> > in a typical Unix, since ssh is probably installed globally.
> >
> > If Cygwin was installed without administrative privileges,
> > creating a dedicated sshd user would be impossible (and makes
> > little sense if sshd runs in single user mode, anyway). I guess
> > it would be possible to add a fake user account in /etc/passwd.
> >
> > Since user sshd and chroot /var/empty are not used in single
> > user mode, it might be better to remove the check in this case:
> >
> > === cut after ===
> > diff --git a/sshd.c b/sshd.c
> > index 010a2c3..4f9b2c8 100644
> > --- a/sshd.c
> > +++ b/sshd.c
> > @@ -1641,7 +1641,8 @@ main(int ac, char **av)
> >
> > /* Store privilege separation user for later use if required. */
> > if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
> > - if (use_privsep || options.kerberos_authentication)
> > + if ((use_privsep || options.kerberos_authentication)
> > + && (getuid() == 0 || geteuid() == 0))
> > fatal("Privilege separation user %s does not exist",
> > SSH_PRIVSEP_USER);
> > } else {
> > @@ -1767,7 +1768,7 @@ main(int ac, char **av)
> > key_type(key));
> > }
> >
> > - if (use_privsep) {
> > + if (use_privsep && (getuid() == 0 || geteuid() == 0)) {
> > struct stat st;
> >
> > if ((stat(_PATH_PRIVSEP_CHROOT_DIR, &st) == -1) ||
> > === cut before ===
> >
> > Best regards,
> >
> > -- Lionel
> > ----- End forwarded message -----
> >
> > Is there a chance this could be reenabled again?
> >
> >
> > Thanks,
> > Corinna
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Encryption key for Jack Dodds.asc

signature.asc

Darren Tucker

unread,

Mar 28, 2017, 10:10:01 PM3/28/17

to Jack Dodds, openssh-unix-dev, Corinna Vinschen

On Tue, Mar 28, 2017 at 2:23 AM, Jack Dodds <brmd...@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 <vins...@redhat.com>
> To: openssh-...@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.

Jack Dodds

unread,

Mar 28, 2017, 10:39:44 PM3/28/17

to Darren Tucker, openssh-unix-dev, Corinna Vinschen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Darren,

Thank you for the explanation. As long as a non-privileged user
can run sshd (listening on a high-numbered port), my application
is OK.

SSH is a great tool for those of us concerned about privacy. Your
work is really appreciated!

Jack

Reply all

Reply to author

Forward