Solar Designer wrote:
On Wed, Oct 08, 2008 at 09:12:23AM +0200, Tomas Mraz wrote:
I think we should do the same as sshd on Linux without PAM enabled - it
will reject just the accounts with password hash that starts with the
'!'. We would not reject the accounts with '*' in the password hash in
the shadow entry.
While the above will simplify locking accounts (no need to check for
authorized_keys* files) and/or result in better security (some
meant-to-be-locked accounts will actually become locked in terms of SSH
access and maybe more), it is problematic in several ways:
1. There are plenty of systems and accounts that _intentionally_ have
their password fields locked (the string starts with "!"), but SSH keys
set up. I am using plenty of such accounts myself.
Agreed, this is an unfortunate consequence of there being two "era"s of
defaults: "linux before PAM", and "linux with PAM", with sysadmins
accustomed to one or the other dependent on experience. So yes, if we
enhance pam_unix to be capable of fully respecting the semantics of the
systems it replaces, it must be optional, because to many systems have
since grown to rely on PAM's unwittingly changed convention.
2. Allowing access for accounts with "*" in the password hash field,
while disallowing it for those with "!" as the first character, might be
wrong.
What's wrong about this? I am _not_ suggesting that PAM do anything more
complex than support the traditional convention of "first character of
password == ! indicates entire account (not just password) is locked".
It's purely about supporting traditional behaviour fully, not adding new
features.
It will limit the extent of this new security measure to newly created
and locked accounts, all of which could use SSH keys on purpose. The
new security measure will not apply to system-reserved accounts,
although there's usually no need to permit logins to those. (Well, in
some cases it may make sense to "su" to them, and "su" may use the PAM
"account" stack too...)
Yes, a similar change that is already in OpenSSH portable has resulted
in some people using "*" in the password hash field as a workaround (I
am aware of specific occasions), and I am sure that if Linux-PAM does
the same, even more people (admins) will be "manually" changing password
hash fields to "*" (or to start with a "*") to allow access with SSH
public key authentication. However, this results in "*" no longer
representing system-reserved accounts only, which may be unfortunate.
I was not aware anyone considered "*" as representing a system-reserved
account. Can you please elaborate on why you think it should/does
represent that?
Also, one has to deal with the password hash string, even if via the
proper tools, to configure an account like that. "usermod -L" and
"passwd -l" are "admin-friendly" approaches; there's no equivalent that
would be as friendly for "*-locking" (and "*-unlocking") an account.
Well, there's "usermod -p\* ACCT" and that has always been satisfactory
for me.
3. Dealing with password authentication and SSH access might not be
sufficient to ensure that the account has no other "backdoors" on it.
Other ways to retain / re-gain access to an account include cron jobs,
at jobs, .forward and .procmailrc files (invoking programs).
Yes, but why is this relevant to the discussion at hand? PAM just needs
to ensure its stacks behave appropriately, it is the responsibility of
other applications to actually call them.
Unfortunately, this does not address the problem of not having a
convenient way to set individual accounts to "non-password
authentication only", while allowing for use of this new functionality.
What's wrong with "usermod -p\*"? (Would need to be documented, of course.)
Alternatively, the meaning of "!" can be changed to "password locked"
rather than "account locked" (in fact, this will mostly bring the
documentation in sync with today's reality, with no code changes other
than to OpenSSH portable)
My impression (which may be wrong, please correct me if so) is that the
change in today's reality is only because this check got missed out of
pam_unix when it was first written. As such, I prefer rectifying that
oversight.
