bugzilla-daemon at mindrot.org
2013-Jan-14 08:51 UTC
[Bug 2061] New: Request for PermitRootLogin to be enforced prior to credential check
https://bugzilla.mindrot.org/show_bug.cgi?id=2061 Bug ID: 2061 Summary: Request for PermitRootLogin to be enforced prior to credential check Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: Other OS: OpenBSD Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: vram at tradermail.info Unless I am misreading the code, at present, when an attempt is made to log in as "root", first the login attempt is authenticated. Only afterwards is auth_root_allowed(...) called. Thus if someone wants to try to login as root via ssh even when PermitRootLogin=no it is only *after* they succesfully use the correct password/key that the option is enforced, and the "ROOT LOGIN REFUSED" log message is emitted. Otherwise, it is logged like any other failed attempt. However, if we have PermitRootLogin=no set, then knowing immediately via the big glaring "ROOT LOGIN REFUSED" log message sooner rather than later allows the administrator to more quickly and easily know that an inappropriate access attempt is being made. After all, this log message exists for a reason. I'd like to politely request that PermitRootLogin be honored by instead enforcing the negative option values even prior to checking the credentials. Once authctxt->pw is valid and the corresponding UID is known to be 0, then auth_root_allowed(...) should be called upstream of the userauth(...) call for that authctxt. Thanks for your consideration and for OpenSSH. -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2013-Jan-15 08:29 UTC
[Bug 2061] Request for PermitRootLogin to be enforced prior to credential check
https://bugzilla.mindrot.org/show_bug.cgi?id=2061 --- Comment #1 from V. Ram <vram at tradermail.info> --- Created attachment 2208 --> https://bugzilla.mindrot.org/attachment.cgi?id=2208&action=edit Patch to auth2.c to move check to see if permissible root login is being attempted prior to calling m->userauth I apologize ahead of time for any whitespace, formatting, or style screwups. I basically moved the check being done for whether the user is root and the method is permitted by the configuration out of userauth_finish(...) and up into input_userauth_request(...). This should satisfy the gist of what I'm asking. -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2013-Jun-05 01:09 UTC
[Bug 2061] Request for PermitRootLogin to be enforced prior to credential check
https://bugzilla.mindrot.org/show_bug.cgi?id=2061 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Darren Tucker <dtucker at zip.com.au> --- In general we try to leak as little information as possible to a potential attacker, and this would give them an early warning that they'll be denied by policy. (strictly by that policy sshd wouldn't tell you why it's not permitting the login at all, so in theory we should be removing the ROOT LOGIN REFUSED message entirely). sorry, but if anything we'll be making it less obvious rather than more. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
bugzilla-daemon at bugzilla.mindrot.org
2016-Aug-02 00:42 UTC
[Bug 2061] Request for PermitRootLogin to be enforced prior to credential check
https://bugzilla.mindrot.org/show_bug.cgi?id=2061 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #3 from Damien Miller <djm at mindrot.org> --- Close all resolved bugs after 7.3p1 release -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.
Possibly Parallel Threads
- PermitRootLogin and Tru64 SIA
- [Bug 325] PermitRootLogin forced-commands-only & privsep - not working together
- PermitRootLogin without-password functionality differs for UsePAM yes/no option
- 3.7.1P2, PermitRootLogin and PAM with hidden NISplus passwor ds
- "PermitRootLogin no" fails