similar to: [Bug 442] sshd allows login via public-key when account locked

http://bugzilla.mindrot.org/show_bug.cgi?id=442 Summary: sshd allows login via public-key when account locked Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=442 ------- Additional Comments From dtucker at zip.com.au 2003-05-11 12:07 ------- Further info: it appears that in later patch sets, Solaris 8 and 9 now check the password string against *LK* in PAM and deny access even for non-password authentications (eg rhosts).

http://bugzilla.mindrot.org/show_bug.cgi?id=442 ------- Additional Comments From dtucker at zip.com.au 2002-11-24 14:25 ------- Created an attachment (id=181) --> (http://bugzilla.mindrot.org/attachment.cgi?id=181&action=view) Test for locked account in allowed_user() Tested on Redhat 8 and Solaris 8. ------- You are receiving this mail because: ------- You are the assignee for

http://bugzilla.mindrot.org/show_bug.cgi?id=442 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-01-07 12:19

http://bugzilla.mindrot.org/show_bug.cgi?id=278 Darren.Moffat at Sun.COM changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From Darren.Moffat at Sun.COM

Hi! I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. It seems that if I use public key authentication I can log in to an account that is locked (/etc/shadow has *LK* as password). Login is also allowed even if the user does not have a valid shell. Is this a bug or am I missing something? -- Osmo Paananen

Hi Damien, I noticed you merged a couple of ifdefs in the fix for bug #442. The cvs comment says "Fix Bug #442 for PAM case". The code is now roughly: #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) spw = getspnam(pw->pw_name); passwd = spw->sp_pwdp; #else passwd =

http://bugzilla.mindrot.org/show_bug.cgi?id=278 Summary: ssh allows auto login even if account is locked Product: Portable OpenSSH Version: 3.0.2p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=1083 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au --- Comment #13 from Darren Tucker <dtucker at

http://bugzilla.mindrot.org/show_bug.cgi?id=1083 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1148| |ok? Flag| | ------- Comment #10 from dtucker at zip.com.au 2006-06-23 21:15 -------

--- sshd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sshd.c b/sshd.c index dda8d9b77..cbdced5db 100644 --- a/sshd.c +++ b/sshd.c @@ -1533,6 +1533,8 @@ main(int ac, char **av) } else { do_log2(ll, "Unable to load host key: %s", options.host_key_files[i]); + sshkey_free(pubkey); + pubkey = NULL; sensitive_data.host_keys[i] = NULL;

I just ran into what I'd describe as an unexpected side-effect. I don't think it's necessarily a bug, and I don't need any assistance in working around it, but this information might be useful to others for troubleshooting. This was using OpenSSH built under Solaris 2.5.1, and running under 2.5.1 or 8. The symptom was that after upgrading from 3.7.1p1 to 3.7.1p2, some accounts

https://bugzilla.mindrot.org/show_bug.cgi?id=1696 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED CC|

I have a situation where a number of potentially hostile clients ssh to a host I control, each ssh'ing in as the same user, and each forwarding a remote port back to them. So, the authorized_keys file looks like: no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7" ssh-rsa AAAAB....vnRWxcgaK9xXoU= client1234 at example.com

https://bugzilla.mindrot.org/show_bug.cgi?id=1270 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME CC|

https://bugzilla.mindrot.org/show_bug.cgi?id=2430 Bug ID: 2430 Summary: ssh-keygen should allow to login before reading public key from smart card Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=1290 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Darren Tucker <dtucker at zip.com.au> 2010-03-26 10:51:25 EST --- With the

https://bugzilla.mindrot.org/show_bug.cgi?id=1523 Summary: Log public key identifier on pubkey login Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

http://bugzilla.mindrot.org/show_bug.cgi?id=720 Summary: "UseDNS no" breaks public key login Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org ReportedBy:

http://bugzilla.mindrot.org/show_bug.cgi?id=475 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From dtucker at zip.com.au 2003-01-26