adduser: what is the difference between --disabled-password and--disabled-login
Shaul Karl
With the --disabled-login option, the account will be created but
will be disabled until a password is set. The --disabled-password
option will not set a password, but login are still possible for
example through SSH RSA keys.
I wonder what is the difference? Alternatively, how adduser accomplish
that? The relevant source lines seem to be:
} elsif ($arg eq "--disabled-password") {
$ask_passwd = 0;
$disabled_login = 0;
} elsif ($arg eq "--disabled-login") {
$ask_passwd = 0;
$disabled_login = 1;
}
if ($ask_passwd) {
&systemcall('/usr/bin/passwd', $new_name);
} else {
if(!$disabled_login) {
&systemcall('/usr/sbin/usermod', '-p', '*', $new_name);
}
}
Perhaps what I really should have asked is about the contents of
/etc/{passwd,shadow}'s password field for disabled accounts.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Haber
>adduser(8) states that
>
> With the --disabled-login option, the account will be created but
> will be disabled until a password is set. The --disabled-password
> option will not set a password, but login are still possible for
> example through SSH RSA keys.
>
>I wonder what is the difference?
One disables the account, the other sets an invalid password. I think
that the manpage is quite clear about that.
> if ($ask_passwd) {
> &systemcall('/usr/bin/passwd', $new_name);
> } else {
> if(!$disabled_login) {
> &systemcall('/usr/sbin/usermod', '-p', '*', $new_name);
> }
> }
>
>Perhaps what I really should have asked is about the contents of
>/etc/{passwd,shadow}'s password field for disabled accounts.
One is "*", the other is "!". I never know which is which.
Why didn't you ask the adduser maintainers?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Stephen Gran
> On Mon, 09 May 2005 15:34:06 +0300, Shaul Karl <sha...@013.net> wrote:
> >adduser(8) states that
> >
> > With the --disabled-login option, the account will be created but
> > will be disabled until a password is set. The --disabled-password
> > option will not set a password, but login are still possible for
> > example through SSH RSA keys.
> >
> >I wonder what is the difference?
>
> One disables the account, the other sets an invalid password. I think
> that the manpage is quite clear about that.
>
> >/etc/{passwd,shadow}'s password field for disabled accounts.
>
> One is "*", the other is "!". I never know which is which.
* is disabled, IIRC, and ! is an invalid password (but would still allow
logging in with, e.g, an ssh key). Or so my (often faulty) memory says.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Shaul Karl
> This one time, at band camp, Marc Haber said:
> > On Mon, 09 May 2005 15:34:06 +0300, Shaul Karl <sha...@013.net> wrote:
> > >adduser(8) states that
> > >
> > > With the --disabled-login option, the account will be created but
> > > will be disabled until a password is set. The --disabled-password
> > > option will not set a password, but login are still possible for
> > > example through SSH RSA keys.
> > >
> > >I wonder what is the difference?
> >
> > One disables the account, the other sets an invalid password. I think
> > that the manpage is quite clear about that.
> >
> > >Perhaps what I really should have asked is about the contents of
> > >/etc/{passwd,shadow}'s password field for disabled accounts.
> >
> > One is "*", the other is "!". I never know which is which.
>
> * is disabled, IIRC, and ! is an invalid password (but would still allow
> logging in with, e.g, an ssh key). Or so my (often faulty) memory says.
According to shadow(5),
If the password field contains some string that is not valid result of
crypt(3), for instance ! or *, the user will not be able to use a unix
password to log in, subject to pam(7).
The way I understand it, the effect of ! or * is identical.
Alternatively, the difference is set by the configuration of pam, which,
I believe, is out of adduser scope. This match my experience that login
through SSH RSA key is possible even if a '!' is used.
In any case, am I right that adduser's --disabled-login and
--disabled-password looks to be the same?
> Why didn't you ask the adduser maintainers?
>
I need to verify my experience: am I wrong that on a default Debian
system a '!' doesn't prevent login through SSH RSA key? Perhaps a
wishlist bug should be submitted against pam?
Marc Haber
>The way I understand it, the effect of ! or * is identical.
No.
>Alternatively, the difference is set by the configuration of pam, which,
>I believe, is out of adduser scope. This match my experience that login
>through SSH RSA key is possible even if a '!' is used.
> In any case, am I right that adduser's --disabled-login and
>--disabled-password looks to be the same?
Once again, it is "UsePam yes" in the default /etc/ssh/sshd_config
which breaks things.
If that option is switched off, an account created with adduser
--disabled-login is impossible to ssh into (log entry "sshd[14704]:
User testuser not allowed because account is locked") while an account
created with adduser --disabled-password can ssh in fine via
authorized_keys.
"UsePam yes" is generally a _big_ surprise for the local admin since
it allows passwords to be used even if "UsePasswordAuthentification
no" is set in sshd_config.
Looks like we have just found the second security option which is
broken by "UsePam yes". Bad, very bad.
Russ Allbery
> "UsePam yes" is generally a _big_ surprise for the local admin since it
> allows passwords to be used even if "UsePasswordAuthentification no" is
> set in sshd_config.
Yes, because UsePam doesn't use password authentication; it just uses
passwords to authenticate. *sigh*. The sshd documentation is
particularly bad in this area.
To share what took me hours to figure out: There are two authentication
mechanisms in SSH that use passwords. One is called "password" and the
other is called "keyboard-interactive". When sshd_config talks about the
option UsePasswordAuthentication, it's not speaking in English, it's
speaking in terms of the SSH protocol and is talking about disabling the
password *authentication method*. The authentication method
keyboard-interactive may still be enabled.
To add an additional twist, OpenSSH uses keyboard-interactive to talk to
itself, but a lot of the other SSH clients out there only know password.
Any corrections welcome; I figured out the above by reading the source
code and looking at protocol traces and I may still have the details
wrong.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Brian May
Marc> If that option is switched off, an account created with
Marc> adduser --disabled-login is impossible to ssh into (log
Marc> entry "sshd[14704]: User testuser not allowed because
Marc> account is locked") while an account created with adduser
Marc> --disabled-password can ssh in fine via authorized_keys.
I would speculate that the pam_unix module doesn't support checking
the account is locked or not, it only checks to see if it can match
the password. However, as no password is used...
Is there any reason why pam_unix doesn't check if the account is
locked?
Along similar lines, I have noticed general weirdness with pam_ldap.
According to tests I just conducted (OK means login allowed, Fail
means login failed):
| password | RSA
| courier-imap | openssh | openssh
--------------------+--------------+---------+--------------------
expired password | OK | Fail[1] | Fail[2]
account deactive[3] | Fail | Fail | OK
------------------------------------------------------------------
I find this inconsistency is very confusing. What happened (in my
case) is most users on my system log in via courier-imap and never
realize that their password has expired, because it continued
working. Then they came to a trivial problem that took ages to fix
because first I had to debug why ssh wouldn't let them log in using a
password.
I also find it incredible that an expired LDAP password will prevent
RSA based log ins (WHY?), but a deactive account won't (WHY not?).
I also think it would be really "cool"(TM) if the system could display
a message "password expired" or "account is locked" if the user
successfully authenticates to the system but is unable to authorize
the user to use the system. This saves the user wondering "did I use
the correct password?", "Did I enter it in correctly?", etc.
Notes:
[1] Nothing displayed to user, but following logged:
May 15 10:46:24 snoopy sshd[15018]: error: PAM: User account has expired for jan from localhost
[2] Automatically reverts to password based authentication which
fails, but in this case it never displays the expired message.
May 15 10:50:53 snoopy sshd[15846]: error: PAM: Authentication failure for jan from localhost
[3] "Account deactivated" option in "LDAP Account Manager". I haven't
worked out how this is stored in LDAP yet. No messages displayed to
the user.
--
Brian May <b...@debian.org>
Steve Langasek
> >>>>> "Marc" == Marc Haber <mh+debi...@zugschlus.de> writes:
>
> Marc> If that option is switched off, an account created with
> Marc> adduser --disabled-login is impossible to ssh into (log
> Marc> entry "sshd[14704]: User testuser not allowed because
> Marc> account is locked") while an account created with adduser
> Marc> --disabled-password can ssh in fine via authorized_keys.
> I would speculate that the pam_unix module doesn't support checking
> the account is locked or not, it only checks to see if it can match
> the password.
That's incorrect.
> Is there any reason why pam_unix doesn't check if the account is
> locked?
It does, if you use the authorization checks in PAM. If you only use the
authentication checks, then PAM is only going to authenticate the user --
not check whether they're allowed access.
> I also think it would be really "cool"(TM) if the system could display
> a message "password expired" or "account is locked" if the user
> successfully authenticates to the system but is unable to authorize
> the user to use the system. This saves the user wondering "did I use
> the correct password?", "Did I enter it in correctly?", etc.
This leaks information to attackers about the state of the account.
--
Steve Langasek
postmodern programmer
Glenn Maynard
> > I also think it would be really "cool"(TM) if the system could display
> > a message "password expired" or "account is locked" if the user
> > successfully authenticates to the system but is unable to authorize
> > the user to use the system. This saves the user wondering "did I use
> > the correct password?", "Did I enter it in correctly?", etc.
>
> This leaks information to attackers about the state of the account.
Hence "could": I don't consider the fact that an account is expired or
locked (or exists, for that matter) to be sensitive information, for
my uses, and would much prefer to give proper error messages. People
with different security needs/philosophies use different policies ...
(I'd be satisfied if I could convinced logins/su to not force a pointless
delay on an incorrect password--the only thing more annoying than mistyping
my password is having my own system force me to wait. One of these days I'll
get annoyed enough by this to track down why "FAIL_DELAY 0" isn't being
honored ...)
--
Glenn Maynard
Steve Langasek
> On Sat, May 14, 2005 at 07:22:56PM -0700, Steve Langasek wrote:
> > > I also think it would be really "cool"(TM) if the system could display
> > > a message "password expired" or "account is locked" if the user
> > > successfully authenticates to the system but is unable to authorize
> > > the user to use the system. This saves the user wondering "did I use
> > > the correct password?", "Did I enter it in correctly?", etc.
> > This leaks information to attackers about the state of the account.
> Hence "could": I don't consider the fact that an account is expired or
> locked (or exists, for that matter) to be sensitive information, for
> my uses, and would much prefer to give proper error messages. People
> with different security needs/philosophies use different policies ...
The trouble with doing this, in PAM-based systems, is that authentication
precedes authorization; so any message that informs the user that the
account is not authorized (i.e., it's expired or locked) also informs the
attacker that authentication succeeded.
So, it's not just information about the account state that's being leaked;
you're also leaking authentication tokens.
Brian May
Steve> It does, if you use the authorization checks in PAM. If
Steve> you only use the authentication checks, then PAM is only
Steve> going to authenticate the user -- not check whether they're
Steve> allowed access.
When you say "authorization checks" vs "authentication checks" what do
you mean?
PAM has the following sections "auth", "account", "password",
"session". All of these are configured by default on Debian. The
implication I got when reading Marc's post (or did I read too much
into it?) is if ssh is configured to use PAM and if you use RSA based
authentication, it won't detect if the account is locked.
I fail to see where terms like "authorization" and "authentication"
fit into its configuration scheme.
If I did misread Marc's post, and pam_unix does the right thing, this
doesn't excuse pam_ldap for not doing the right thing either (as shown
in my test results I already posted).
Steve> This leaks information to attackers about the state of the
Steve> account.
Only if the attackers are able to successfully authenticate as you. If
they can authenticate as you, then security is potentially lost
anyway, right? ...unless the solution to the error is to update the
password, but in that case leaking the information doesn't have any
downside.
Perhaps the only exception I can think of is if the account is locked
due to "too many login attempts" as opposed to "password expired" or
"account has expired" or some other predictable reason. Then, yes,
that would be a problem.
Steve Langasek
> >>>>> "Steve" == Steve Langasek <vor...@debian.org> writes:
> Steve> It does, if you use the authorization checks in PAM. If
> Steve> you only use the authentication checks, then PAM is only
> Steve> going to authenticate the user -- not check whether they're
> Steve> allowed access.
> When you say "authorization checks" vs "authentication checks" what do
> you mean?
> PAM has the following sections "auth", "account", "password",
> "session". All of these are configured by default on Debian. The
> implication I got when reading Marc's post (or did I read too much
> into it?) is if ssh is configured to use PAM and if you use RSA based
> authentication, it won't detect if the account is locked.
> I fail to see where terms like "authorization" and "authentication"
> fit into its configuration scheme.
The PAM "auth" section is for authentication, and the "account" section is
for (account) authorization.
Frederik Dannemare
[ ... ]
> "UsePam yes" is generally a _big_ surprise for the local admin since
> it allows passwords to be used even if "UsePasswordAuthentification
> no" is set in sshd_config.
I have exactly those set on a few hosts:
foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config
PasswordAuthentication no
UsePAM yes
But from client hosts with no proper pubkey, I get :
$ ssh foohost
Permission denied (publickey).
From what you mention above, I should actually be prompted for a
password, right? I only remember setting "PasswordAuthentication no" in
sshd_config and I haven't touched any PAM stuff (ie. default Sarge
settings).
Best regards,
--
Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://www.ubuntulinux.org/wiki/FrederikDannemare
Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E
Frederik Dannemare
> On Thursday 12 May 2005 20:18, Marc Haber wrote:
> [ ... ]
>
> > "UsePam yes" is generally a _big_ surprise for the local admin
> > since it allows passwords to be used even if
> > "UsePasswordAuthentification no" is set in sshd_config.
>
> [ ... ]
>
> I have exactly those set on a few hosts:
> foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config
> PasswordAuthentication no
> UsePAM yes
>
> But from client hosts with no proper pubkey, I get :
> $ ssh foohost
> Permission denied (publickey).
>
> From what you mention above, I should actually be prompted for a
> password, right? I only remember setting "PasswordAuthentication no"
> in sshd_config and I haven't touched any PAM stuff (ie. default Sarge
> settings).
Btw, I have "ChallengeResponseAuthentication no" as well. I suspect this
is why "UsePAM yes" is not a problem here (with respect to allowing
passwords to be used).
--
Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://www.ubuntulinux.org/wiki/FrederikDannemare
Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E