Debian Bug report logs - #219377
SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: sumbit@bugs.debian.org

Subject: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Wed, 5 Nov 2003 20:00:20 -0500

Package: ssh
Version: 3.4p1-1.woody.3
Severity: Important

If a ~/.ssh/authorized_key file exists and a user's account is locked
with 'passwd -l' the user can still log in despite the locked account.

A system administrator who uses passwd to lock the account may not be
aware of the authorized_key file and thus fail to effectively lock the
account.
 
-- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
--
Excuse #145: Short leg on process table 

Message #10 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Jeremy Avnet <brainsik@theory.org>

Cc: debian-ssh@lists.debian.org, 219377@bugs.debian.org

Subject: Re: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 03:10:36 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 05 Nov 2003 at 08:35:25PM -0500, Jeremy Avnet wrote:
> On 5 Nov 2003, at 5:00 PM, Phillip Hofmeister wrote:
> >If a ~/.ssh/authorized_key file exists and a user's account is locked
> >with 'passwd -l' the user can still log in despite the locked account.
> 
> Is this a bug or a feature?
> Is there a better way of going about forcing an account to only accept 
> login with an ssh key?

I guess it may be a feature request, perhaps a configuration option.  It
would make sense that if an account is being disabled that logins would
not be allowed.  I suppose there are some instances where this would not
be the case.

If you think this is a feature/configuration request then it man be
appropriate to mark this bug wishlist and forward it upstream.

- -- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
- --
Excuse #129: Stubborn processes 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qgHlS3Jybf3L5MQRAjCnAKCECECkolXjnW/Ct2oDIaqeFoDylwCePzP7
4yPI83WRMmurVwuG59zlfuc=
=Ui1u
-----END PGP SIGNATURE-----

Message #15 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@sel.cam.ac.uk>

To: Phillip Hofmeister <plhofmei@zionlth.org>, 219377@bugs.debian.org

Subject: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 10:09:48 +0000

Phillip Hofmeister writes:
 > Package: ssh
 > Version: 3.4p1-1.woody.3
 > Severity: Important
 > 
 > If a ~/.ssh/authorized_key file exists and a user's account is locked
 > with 'passwd -l' the user can still log in despite the locked account.
 
This is trivially true - all passwd -l does it make the password field
in the {shadow,passwd} file be a value that nothing encrypts to, thus
preventing successful password authentication.

If a user is using publickey authentication, then no password check is
made (that's rather the point) - therefore it will be impossible to
disable access by simply fiddling with the password file.

Accordingly, if a sysadmin wants to be able to disable accounts using
passwd -l, then they'll have to enforce password authentication on all
logins. 

Matthew 

-- 
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org

Message #20 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Matthew Vernon <matthew@sel.cam.ac.uk>

Cc: 219377@bugs.debian.org

Subject: Re: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 05:28:17 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 06 Nov 2003 at 05:09:48AM -0500, Matthew Vernon wrote:
> This is trivially true - all passwd -l does it make the password field
> in the {shadow,passwd} file be a value that nothing encrypts to, thus
> preventing successful password authentication.
> 
> If a user is using publickey authentication, then no password check is
> made (that's rather the point) - therefore it will be impossible to
> disable access by simply fiddling with the password file.
> 
> Accordingly, if a sysadmin wants to be able to disable accounts using
> passwd -l, then they'll have to enforce password authentication on all
> logins. 

Actually, using passwd -l adds a ! to the front of the password hash
which is easily detected.  In fact, passwd -S can detect this:

smeister L 05/29/2003 5 180 28 30

So I believe this is definitely something that is doable without forcing
passwords for every login.

- -- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
- --
Excuse #187: Fanout dropping voltage too much try cutting some of those little traces 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qiIsS3Jybf3L5MQRAlG9AJwOIPMRrWTlnw0LxSwzQ3Ncx3JjEgCdGyOR
SEJufigXSn53Y6dXMbHiy6A=
=YpHt
-----END PGP SIGNATURE-----

Message #25 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Darren Tucker <dtucker@zip.com.au>

To: 219377@bugs.debian.org, Phillip Hofmeister <plhofmei@zionlth.org>

Subject: Debian bug #219377: further info

Date: Sun, 09 Nov 2003 17:38:09 +1100

Hi.
	I have some further info regarding the Debian bug you reported ("sshd
ignores PAM lockout when using pubkey auth").

	Recently this was addressed in the upstream source (3.7p1 and up) for the
non-PAM case.  On platforms that have a concept of a locked account, sshd
checks for the specific string that denotes a locked account on that
platform.

	When running with PAM enabled, however, sshd delegates all account checks
to PAM.  Thus the locked account check should be done by PAM (probably in
pam_acct_mgmt).

	Later patchlevels of Solaris do this kind of check in PAM (I think in
pam_acct_mgmt, but I'm not sure of that).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Message #30 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Darren Tucker <dtucker@zip.com.au>, 219377@bugs.debian.org

Cc: Phillip Hofmeister <plhofmei@zionlth.org>, control@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Sun, 22 Feb 2004 17:45:07 +0000

severity 219377 wishlist
thanks

On Sun, Nov 09, 2003 at 05:38:09PM +1100, Darren Tucker wrote:
> 	I have some further info regarding the Debian bug you reported ("sshd
> ignores PAM lockout when using pubkey auth").
> 
> 	Recently this was addressed in the upstream source (3.7p1 and up) for the
> non-PAM case.  On platforms that have a concept of a locked account, sshd
> checks for the specific string that denotes a locked account on that
> platform.
> 
> 	When running with PAM enabled, however, sshd delegates all account checks
> to PAM.  Thus the locked account check should be done by PAM (probably in
> pam_acct_mgmt).
> 
> 	Later patchlevels of Solaris do this kind of check in PAM (I think in
> pam_acct_mgmt, but I'm not sure of that).

To lock an account, I think you should set the shell to /bin/false or
/dev/null or similar. Having asked around, I know people who
deliberately lock the password to force public-key authentication only;
implementing this feature request would break that facility.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Message #37 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Colin Watson <cjwatson@debian.org>

Cc: Darren Tucker <dtucker@zip.com.au>, 219377@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Sun, 22 Feb 2004 23:59:22 -0500

It wouldn't break that functionality if it were made a config file
option...

On Sun, 22 Feb 2004 at 12:45:07PM -0500, Colin Watson wrote:
> severity 219377 wishlist
> thanks
> 
> On Sun, Nov 09, 2003 at 05:38:09PM +1100, Darren Tucker wrote:
> > 	I have some further info regarding the Debian bug you reported ("sshd
> > ignores PAM lockout when using pubkey auth").
> > 
> > 	Recently this was addressed in the upstream source (3.7p1 and up) for the
> > non-PAM case.  On platforms that have a concept of a locked account, sshd
> > checks for the specific string that denotes a locked account on that
> > platform.
> > 
> > 	When running with PAM enabled, however, sshd delegates all account checks
> > to PAM.  Thus the locked account check should be done by PAM (probably in
> > pam_acct_mgmt).
> > 
> > 	Later patchlevels of Solaris do this kind of check in PAM (I think in
> > pam_acct_mgmt, but I'm not sure of that).
> 
> To lock an account, I think you should set the shell to /bin/false or
> /dev/null or similar. Having asked around, I know people who
> deliberately lock the password to force public-key authentication only;
> implementing this feature request would break that facility.
> 
> Cheers,
> 
> -- 
> Colin Watson                                  [cjwatson@flatline.org.uk]

-- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import

Message #42 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Darren Tucker <dtucker@zip.com.au>

To: Phillip Hofmeister <plhofmei@zionlth.org>

Cc: Colin Watson <cjwatson@debian.org>, 219377@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Mon, 23 Feb 2004 19:23:36 +1100

Phillip Hofmeister wrote:
> It wouldn't break that functionality if it were made a config file
> option...

	IMO, making sshd second-guess PAM when UsePAM=yes would be the Wrong 
Thing, either all the time or as an option.  Speaking as one of the 
upstream OpenSSH developers, it is very unlikely that such a patch would 
be accepted upstream.  Debian is of course welcome to do whatever they 
see fit.

	If you want that behaviour, you should arrange for PAM to do it. 
Putting policy decisions like this in the hands of the system's admin is 
the whole point of PAM.  (You could do it with a module that tests for 
locked accounts in your sshd PAM account stack.  Such a module would be 
trivial to write if one doesn't already exist.)

	Alternatively, you could recompile OpenSSH 3.7.1p2 without PAM, and it 
will behave as you wish.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Message #47 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 219377@bugs.debian.org

Subject: PAM and shadow and ! and *

Date: Sun, 24 Sep 2006 02:07:10 +0100

[Message part 1 (text/plain, inline)]

Does sshd use PAM's "account" (authorization) mechanism (as opposed to
"auth" (authentication)) when UsePam is enabled? If so then pam_unix
should be able to say "ah, the password starts with a !, therefore the
account is disabled"... according to Steve Langasek[0] this is the case.

[0] http://groups.google.co.uk/group/linux.debian.devel/msg/a54962f20531e4b8

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #52 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 219377@bugs.debian.org

Cc: Debian BTS Control <control@bugs.debian.org>

Subject: re: PAM and shadow and ! and *

Date: Sun, 24 Sep 2006 14:40:06 +0100

[Message part 1 (text/plain, inline)]

clone 219377 -1
reassign -1 libpam-modules
retitle -1 pam_unix: in 'account' mode, deny authorization if user's account is locked
block 219377 by -1
thanks

I did some testing with a test user, ssh and a public key, and it seems
that Steve Langasek is wrong, and pam_unix does not check to see if the
password field is (or is prefixed by) a ! character.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #61 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 219377@bugs.debian.org, 389183@bugs.debian.org

Cc: Sam Morris <sam@robots.org.uk>, shadow@packages.debian.org

Subject: Re: pam_unix: in 'account' mode, deny authorization if user's account is locked

Date: Sun, 24 Sep 2006 18:16:35 -0700

reassign 389183 libpam-modules,passwd
thanks

> I did some testing with a test user, ssh and a public key, and it seems
> that Steve Langasek is wrong, and pam_unix does not check to see if the
> password field is (or is prefixed by) a ! character.

I don't believe I ever said that pam_unix checks whether the password field
is prefixed by a ! character -- I said that pam_unix checks whether an
account is locked.  Apparently, we're using a couple different definitions
of "locked" here.

"Locking" a user's account by munging the password field is a kludge that
overloads the meaning of this field.  If you want to lock a Unix account
such that pam_unix's authorization checks recognize the account as locked,
there is an account expiry field in the shadow file that I believe is much
more appropriate for this.

But it seems that the passwd command doesn't have an option that will set
this field; it has "passwd -l" and "passwd -u", which manage the "!" in the
password field, and it has "passwd -e", which sets password expiry but *not*
account expiry.

Since, as Colin says, there are people who *expect* that editing the
password field only locks the password, not the account, and this has been
the behavior for, oh... about a decade now, I think it would be better if
the passwd -l/-u option would edit the shadow account expiry field *in
addition* to editing the password field as they do know.  This would
maximize compatibility, while giving passwd -l semantics that more exactly
match the manpage documentation.

So I'm assigning this bug to both libpam-modules and passwd, to get input
from the shadow maintainers.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #64 received at 219377-submitter@bugs.debian.org (full text, mbox, reply):

From: Justin Pryzby <justinpryzby@users.sourceforge.net>

To: 219377-submitter@bugs.debian.org

Subject: this bug/#219377 - SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 27 Mar 2008 11:09:26 -0400

#219377 - sshd: Ignores Pam Lockout When using SSH PubKey Auth
http://bugs.debian.org./219377

This problem seems to be resolved by an upload of shadow last year
(see #402329).  passwd -l should now effect a fully locked account.

Could you test that this works as needed?

Message #73 received at 219377-submitter@bugs.debian.org (full text, mbox, reply):

From: "USPS Express Delivery" <felix.rodgers@becloud.es>

To: 219377-submitter@bugs.debian.org

Subject: Please recheck your delivery address (USPS parcel 85454538098)

Date: Wed, 25 Jan 2017 17:14:46 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

Your item has arrived at January 21, but our courier was not able to deliver the parcel.

Review the document that is attached to this e-mail!

Many thanks,
Felix Rodgers,
USPS Senior Support Manager.

[Ground-Label-85454538098.zip (application/zip, attachment)]

Message #78 received at 219377@bugs.debian.org (full text, mbox, reply):

From: "USPS Support" <edwin.weaver@mfsrenovations.com>

To: 219377@bugs.debian.org

Subject: Notification status of your delivery (USPS 04587299)

Date: Thu, 26 Jan 2017 21:09:40 -0700

[Message part 1 (text/plain, inline)]

Dear Customer,

We can not deliver your parcel arrived at January 26.

You can download the shipment label attached!

With thanks and appreciation,
Edwin Weaver,
USPS Office Agent.

[Undelivered-Package-04587299.zip (application/zip, attachment)]

Message #81 received at 219377-submitter@bugs.debian.org (full text, mbox, reply):

From: www-data@vps901.getcadre.com (www-data)

To: 219377-submitter@bugs.debian.org

Subject: Please recheck your delivery address (UPS parcel 07811201)

Date: Sun, 19 Feb 2017 00:21:15 -0500

[Message part 1 (text/plain, inline)]

Dear Customer,



Your item has arrived at February 18, but our courier was not able to deliver the parcel.



Please review delivery label in attachment!



Yours faithfully,

Milton Schaefer,

UPS Senior Delivery Manager.

[UPS-Package-07811201.zip (application/zip, attachment)]

Message #84 received at 219377-submitter@bugs.debian.org (full text, mbox, reply):

From: crystbc3@server.crystalads.mx

To: 219377-submitter@bugs.debian.org

Subject: Please recheck your delivery address (UPS parcel 6344090)

Date: Wed, 8 Mar 2017 19:52:18 -0700

[Message part 1 (text/plain, inline)]

Dear Customer,

This is to confirm that your item has been shipped at March 05.

Please check the attachment for complete details!

Thanks,
Ross Lyons,
UPS Support Manager.

[UPS-Delivery-6344090.zip (application/zip, attachment)]

Send a report that this bug log contains spam.