similar to: [Bug 2061] New: Request for PermitRootLogin to be enforced prior to credential check

I have "PermitRootLogin no" in my sshd_config, but under Tru64 and SIA, the root login attempts still get passed to the SIA system (so I get lots of warnings about failed root logins). On systems with a "max failed attempts" setting, the root account can be locked out this way. I started looking at the code, and I'm not sure I understand what I see. In auth-passwd.c,

http://bugzilla.mindrot.org/show_bug.cgi?id=325 ------- Additional Comments From hlein at progressive-comp.com 2002-07-13 06:14 ------- Seeing this here too; it appears that when auth2.c:userauth_finish is called, forced_command has been cleared (or perhaps, never set in that forked sshd) so the call to auth_root_allowed(method) returns 0. The following patch makes forced-command logins as

Hi, I am using OpenSSH 3.9p1. For " UsePAM yes/no " option with " PermitRootLogin without-password", the server functionality differs. For " UsePAM yes ", the server allows authentication thru password, meanwhile " UsePAM no " does not. I have fixed that problem and the patch is given below.

It works for the "yes" case but not for the "without-password" case. The function that checks (auth_root_allowed(auth_method) is special cased for "password". The Pam case sends "keyboard-interactive/pam" which like all other authentication methods except password succeeds. Here is a patch to make it work for me. Please feel free to criticize as

I'm running version 4.7p1 of OpenSSH on a Linux system (it was originally a RedHat system, but I've changed almost everything.) When I originally built OpenSSH I used the config option --without-pam, and installed the software in /usr/local. I explicitly forbade root login with sshd (by setting the PermitRootLogin to "no" in the sshd_config file), but found that I could login as

Hi all, among other things, we provide shell access to various unix based platforms for our students and university staff. Recently, there has been increasing number of root login attacks on one particular Tru64 machine running OpenSSH. The host is configured with "PermitRootLogin no" but every once in a while SIA auth with TCB enhanced security locks the root account. I suppose

https://bugzilla.mindrot.org/show_bug.cgi?id=2456 Bug ID: 2456 Summary: gssapi-keyex blocked by PermitRootLogin=without-password Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

http://bugzilla.mindrot.org/show_bug.cgi?id=701 Summary: With 'PermitRootPassword without-password' set, root w/pass can still log in with a using 'keyboard-int/pam' Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority:

Hi All, While testing another patch, I found that I could not longer log in as root, even if PermitRootLogin was yes. It seems to be the following code in auth_password: $ cvs diff -r1.48 -r1.49 auth-passwd.c [snip] #ifndef HAVE_CYGWIN - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) + if (pw->pw_uid == 0 && options.permit_root_login !=

[Please keep CC, I'm not in this list] The default settings for PermitRootLogin appears to be 'yes'. Increased number of attacks target the ssh port 22 and root logins directly[1] throught the Internet. Would it be possible to tighten the initial installation by defaulting PermitRootLogin to 'no' (or even in *.c) in forthcoming releases and have administrators relax it if

Hi, the following patch removes some of the Cygwin specific code from OpenSSH. Since Cygwin is able to change the user context on NT/W2K even without a password since the new Cygwin version 1.3.2, there's no need anymore to allow changing the user context only if the sshd user is the same user as the one which logs in or when a password is given. For that reason the whole function

Greetings, I know that part of the following has been discussed here before but please bear with me. We are running on Solaris versions 2.6 - 9 with a NISplus name service. The permissions on the NISplus password map have been modified to limit read access to the encrypted password field of the passwd table to only the entry owner and the table administrators. See:

https://bugzilla.mindrot.org/show_bug.cgi?id=2354 Bug ID: 2354 Summary: please document that PermitRootLogin really checks for uid=0 Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: Documentation

Dear list, since the order of authentication and AFS token/KRB TGT forwarding changed (around 3.0), we have had problems with users accidentally overwriting their credentials from a "password" login with forwarded credentials. E.g. user A logs in as user B, but stays with the AFS permissions of user A. A workaround is to use "-k" on these sessions, but "it worked without

http://bugzilla.mindrot.org/show_bug.cgi?id=486 Summary: "PermitRootLogin no" can implicitly reveal root password Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at

http://bugzilla.mindrot.org/show_bug.cgi?id=486 cjwatson at debian.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From cjwatson at debian.org 2003-05-06 10:08

https://bugzilla.mindrot.org/show_bug.cgi?id=2445 Bug ID: 2445 Summary: Fix gssapi-with-mic support when is set to PermitRootLogin without-password Product: Portable OpenSSH Version: 7.0p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: sshd

https://bugzilla.mindrot.org/show_bug.cgi?id=2164 Bug ID: 2164 Summary: PermitRootLogin=without-password as default Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

Hi all, I think that there is a security problem with the PermitRootLogin option. I asked an root ssh connection: $ ssh root at machine root at machine's password: I typed no password, this prompt stayed in place. In a second time, I changed the PermitRootLogin to no, and then restart ssh server. Third, I typed the password on the previous prompt, and the access was allowed. I then

Hello, I'm currently experiencing the issue laid out in this thread from last year: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106908815129641&w=2 The discussion that ensued resulted in a number of ideas on how best to 'fix' this issue. The two that seemed most reasonable were: 1. implement a pubkey-only option to PermitRootLogin that would only allow root to login