openssh ignores locked account using public key authentication
ky.robinson at gmail.com
Tue Oct 4 16:53:47 MDT 2005
On 10/4/05, Lonnie Olson <fungus at aros.net> wrote:
> SSH will authenticate using a number of different methods. pubkey,
> keyboard-interactive, and password.
> public key authentication uses PAM to do no more than look up the
> home directory of the user. It actually might not use PAM at all and
> just access the file directly. Locking an account has no effect on
> this form of auth.
Locking an account can actually effect publickey authentication as
long as UsePAM is set to yes in the sshd_config and the linux PAM
function pam_acct_mgmt() is working as it should be (as the Solaris
PAM function does). In this scenario sshd will authenticate the user
with publickey and will then call the pam_acct_mgmt and
pam_open_session functions that should fail based on the locked
account (this is how it works on Solaris). If UsePAM is set to no
these functions wouldn't be called and a locked account would be
allowed by publickey.
The best thing anyone can do for SSH security is disable every
non-essential and duplicate authentication method. A typical
configuration I'll use is (auth section only):
# I don't leave things that might matter commented because the
compiled defaults might
# not be what we expect.
# Just because PasswordAuthentication is set to no doesn't mean users
# by way of passwords, this is being done by PAM. Why would we want two methods
# doing the same thing. Just let PAM do it and do it right/better.
# Challenge response means exactly that. This is dialog driven
# something in PAM wants something other than a static "passwd:" this
will allow PAM
# to ask for it. For example: "Enter user's new password:" "enter token:"
# Kerberos is cool, but in SSH, GSSAPI is cooler
# And of course, our good friend PAM.
More information about the PLUG