Hi, Does anyone set sshd's UseLogin=yes? If so, why? I'd like to remove this option - I've not needed it in the last 15 years on any platform (making it a very poorly-tested code path) and it breaks a few things including post-authentication privilege separation. Can anyone speak in its defence? -d
On 08/16/2016 05:27 AM, Damien Miller wrote:> Hi, > > Does anyone set sshd's UseLogin=yes? If so, why? > > I'd like to remove this option - I've not needed it in the last 15 years > on any platform (making it a very poorly-tested code path) and it breaks > a few things including post-authentication privilege separation. > > Can anyone speak in its defence?No. We recently marked this option as deprecated in Fedora (throws a warning in the logs) and removing it sounds like a good idea to me (it does not even work with SELinux enforcing). I set UseLogin=yes only for rare testing purposes. Regards, -- Jakub Jelen Security Technologies Red Hat
On 08/16/16 05:27, Damien Miller wrote:> Hi, > > Does anyone set sshd's UseLogin=yes? If so, why? > > I'd like to remove this option - I've not needed it in the last 15 years > on any platform (making it a very poorly-tested code path) and it breaks > a few things including post-authentication privilege separation.+1 to remove UseLogin Tomas
On Tue, Aug 16, 2016 at 01:27:00PM +1000, Damien Miller wrote:> Does anyone set sshd's UseLogin=yes? If so, why?I've used it in a vendor hacked version of sshd (boks_sshd, from Fox Technologies) because that didn't have PAM support (it had its own AAA subsystem that was more flexible - eg separate rules for SCP, login shell, non-login remote commands, SFTP and so on). This meant that things like pam_limits didn't work; UseLogin was a workaround for the rare cases where it was needed. The vendor has since fixed their code to support PAM "session" so it's not even needed there, any more. But that's the only place I've needed UseLogin :-) -- rgds Stephen