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.> 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-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: Encryption key for Jack Dodds.asc Type: application/pgp-keys Size: 1702 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/68e672e1/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP Digital Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170327/68e672e1/attachment-0003.bin>
Darren Tucker
2017-Mar-29 02:03 UTC
Is support being removed for ordinary users to run sshd?
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.
-----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 Darren Tucker <dtucker at zip.com.au> wrote:> 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 >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY2xywAAoJEChpvIQG4DsHRngIAIFlboNrrJ8dKoOSFOex6lIy dwH92dF3gsIdHB2Uuya8UElfi+fHl1Rypc3ToDT53lbGJTI3N/ERY7VK5vs69UFz BlKQ8tD+E43VBmM6dqWAIXY2t+DDdOn/pg1zC8sWIxoH/YvKGUp+dqMIHpnjnVyQ DKxQUiv+ygXapJGaNwIe8lFicdxyqerwxXJX9gwbs73iTTEK7sfqK9WGoTox5yqN PORJi73zmjBastFKvO+wDM4F+5xXtX4cH9eufNa/eAouZpIVpUut5MwGbL0LDVNL 8jeolgLZMx/dnBpgy8eezUXnF6e41k0y7Iw0LFmzCYHBGQ82lyn4TxV/BG/+QrQ=B/Dp -----END PGP SIGNATURE-----