Re: [Cooker] sshd - cannot change expired password/no user login
On tisdagen den 13 augusti 2002 00.50 Vincent Danen wrote: On Sun Aug 11, 2002 at 02:26:39PM -0400, Oden Eriksson wrote: [...] Or perhaps just ignore the privsep bsd shit and continue as before?, the huge security hole is gone anyway... That's the problem.. you can't. Disabling privsep doesn't remove it from the code. The introduction of privsep changed some of the fundamental code in openssh; as it's been pointed out before, password aging just doesn't work period in openssh right now, regardless of whether privsep is enabled or not. So, to continue on as before, would be to downgrade openssh to a pre-privsep version. Yes I just checked the code and it's pretty hard to remove it, and theo would probably not approve ;) No, Theo wouldn't approve and would end up bitching me out (again). =) I've heard about it, amazing bitch. I also checked in their bugzilla, and there's not much regarding this privsep bug at all in there from what I could tell. There should be a whole slew, but probably listed under various problems with pam. This is definately a known issue. Once I have a little extra time, I will start fiddling with the cvs version of openssh and see if they are actually fixing this stuff. Ahh, of course. My fault for not searching the right keyword (and had the patience to wait for bugzilla in and output). I will try to check this in CVS too, I'll keep you posted. Chears. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] sshd - cannot change expired password/no user login
On Tue Aug 13, 2002 at 07:29:20PM -0400, Oden Eriksson wrote:
[...]
Yes I just checked the code and it's pretty hard to remove it, and theo
would probably not approve ;)
No, Theo wouldn't approve and would end up bitching me out (again).
=)
I've heard about it, amazing bitch.
Yeah... he's pretty good at it. Quite talented.
I also checked in their bugzilla, and there's not much regarding this
privsep bug at all in there from what I could tell.
There should be a whole slew, but probably listed under various
problems with pam. This is definately a known issue. Once I have a
little extra time, I will start fiddling with the cvs version of
openssh and see if they are actually fixing this stuff.
Ahh, of course. My fault for not searching the right keyword (and had the
patience to wait for bugzilla in and output).
=) bugzilla's a little bloated, that's for sure.
I will try to check this in CVS too, I'll keep you posted.
Cool. Thanks.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg70382/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Sun Aug 11, 2002 at 02:26:39PM -0400, Oden Eriksson wrote:
[...]
Or perhaps just ignore the privsep bsd shit and continue as before?, the
huge security hole is gone anyway...
That's the problem.. you can't. Disabling privsep doesn't remove it
from the code. The introduction of privsep changed some of the
fundamental code in openssh; as it's been pointed out before, password
aging just doesn't work period in openssh right now, regardless of
whether privsep is enabled or not. So, to continue on as before,
would be to downgrade openssh to a pre-privsep version.
Yes I just checked the code and it's pretty hard to remove it, and theo would
probably not approve ;)
No, Theo wouldn't approve and would end up bitching me out (again).
=)
I also checked in their bugzilla, and there's not much regarding this privsep
bug at all in there from what I could tell.
There should be a whole slew, but probably listed under various
problems with pam. This is definately a known issue. Once I have a
little extra time, I will start fiddling with the cvs version of
openssh and see if they are actually fixing this stuff.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg70248/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Fri Aug 09, 2002 at 04:34:46PM -0700, Ben Reser wrote:
Ok, blows have my argument away but strengthens my argument that the
openbsd team really don't know what they're doing.
Why they would put their primary FTP site on Solaris when openbsd runs
just peachy on sparc is beyond me. That's just plain stupid.
It's quite possible that their ftp site is hosted by someone else who is
donating hardware and bandwidth. Beggars can't be choosers.
Hmmm... that could be true.
I would give Theo the benefit of the doubt, but I don't think he
really deserves it.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg70249/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On fredagen den 9 augusti 2002 16.28 Vincent Danen wrote: On Fri Aug 09, 2002 at 07:33:09PM -0400, Oden Eriksson wrote: [...] The last problem _was_ with privsep disabled. It still does not work. Sorry to ask but have you tested it? Chage user, set password change time in the past and try to log in (using public key as in my case). Yup, you're absolutely right. The way privsep is written changes the way the whole pam interaction is done. Unfortunately, there is no easy way around this except to downgrade to a pre-3.3p1 version. =( Or perhaps just ignore the privsep bsd shit and continue as before?, the huge security hole is gone anyway... That's the problem.. you can't. Disabling privsep doesn't remove it from the code. The introduction of privsep changed some of the fundamental code in openssh; as it's been pointed out before, password aging just doesn't work period in openssh right now, regardless of whether privsep is enabled or not. So, to continue on as before, would be to downgrade openssh to a pre-privsep version. Yes I just checked the code and it's pretty hard to remove it, and theo would probably not approve ;) I also checked in their bugzilla, and there's not much regarding this privsep bug at all in there from what I could tell. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] sshd - cannot change expired password/no user login
On Fri Aug 02, 2002 at 01:33:08PM +0400, Borsenkow Andrej wrote:
[...]
Hmmm, I thought this was only a server side thing... Does your
sshd_config
look like this UsePrivilegeSeparation no on the server, and (silly
question) have you restarted the sshd (stop|start)?.
Right. privsep is only useful server-side.
I have disabled it on server side. And I have restarted server after it.
With privsep enabled it fails differently (just closes connection with
different messages logged).
Yup, you're right... I have been looking at openssh some more and the
privsep code changed the whole pam interaction. With or without
privsep, you'll still have these problems.
Solar Designer wrote a patch to 3.4p1 that fixes a lot of this stuff,
but it requires additional pam changes that we don't have. I would
like to integrate it since I'm not sure when 3.5 will be out and if it
will fix these things, but it requires changing a lot of stuff.
This whole openssh thing is turning into a big PITA.
[...]
Right. With privsep disabled, sshd will do all the pam stuff as root
which should work just as it always did.
The last problem _was_ with privsep disabled. It still does not work.
Sorry to ask but have you tested it? Chage user, set password change
time in the past and try to log in (using public key as in my case).
Yup, you're absolutely right. The way privsep is written changes the
way the whole pam interaction is done.
Unfortunately, there is no easy way around this except to downgrade to
a pre-3.3p1 version. =(
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69753/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Thu Aug 01, 2002 at 09:04:33PM +0200, Han wrote:
that means that sshd in default installation has large bug. If
privsep results in complete user lockout, then _PLEASE_ disable it
by default.
There are some little quirks with privsep and pam due to how privsep
tries to do the authentication as a non-root user. As soon as a new
openssh comes out that fixes this, it will go into updates all over
the place.
The OpenSSH team stated in a message that they were having lots of
problems with all the different versions of pam. I think it would be
wise to to provide a pam-version that gives the OpenSSH team the least
headaches. Or rather to take that also in account when working on pam.
Right. But which pam version do we use as a basis? openssh has a
responsibility to make it work with every pam out there, whether it be
for Linux, Solaris, or whatever. That's the whole point of portable
openssh.
I wouldn't say they had this responsibility if they hadn't forced
privsep on everyone. For them to do so without proper compatability
is irresponsible. They more or less forced all vendors to upgrade to
their privsep-enabled/pam-broken openssh because of a bug that could
be circumvented quite easily (ie. disabling a few things, no
problems). Instead, they introduced something that isn't 100% and is
causing problems for more people than just those using Mandrake.
I'm not comfortable with disabling privsep for a few reasons. For one,
it is extremely valuable... it's (to me) an essential feature. And not
everyone does password aging (which is the problem here).
I am sure privsep has much more impact than you can achieve by enforcing
password aging.
Oh, I'm sure there is. privsep has not had enough testing to be 100%
yet... pam is just the most obvious. I'm sure there are others (IIRC,
reverse-resolution DNS lookups is also a problem). I read the openssh
list and there are a *lot* of problems with 3.4p1; not all of them are
privsep related, but there are a lot of problems.
[snip]
As well, considering how badly the openbsd/openssh teams are fscking
things up these days, I think having privsep there is almost
essential.
Not refering to:
http://slashdot.org/articles/02/08/01/129228.shtml?tid=172
Why not refer to this? Is not the openbsd FTP site running on
openbsd? I'm sure I'm not the only person who assumed that openbsd
was supposed to be secure. Hell, I feel sorry for those people who
chose to use openbsd because if it's apparently much-more-secure base
system. In the last few months there has been ongoing proof that
openbsd is not as secure as it claims. I think a well-secured Linux
system can be just as secure as openbsd, considering a remote hole in
openssh (installed default), and now their FTP site being penetrated
for a trojan. What more evidence do you want that openbsd is not the
be-all and end-all of OS security?
But this doesn't have much to do with openssh other than to prove a
point: mistakes have been made, and increasingly so with the
open{bsd,ssh} teams lately.
But for the rest the OpenSSH team are finding bugs. They were always
there and they remove them and tell everybody that they did find
something. Anyway you don't sound like someone who knows all the facts,
more like someone who has heard something.
Right. You tell me I don't know all the facts yet you don't provide
any illustration that what I've said is not factual.
Is openbsd not as secure as has been previously reported? No it's
not. Fact.
Does openssh not play well with PAM? No, it does not. Fact.
Did the openssh team force an upgrade path to a version that was known
not to work in the same way as previous versions because of an
undisclosed remote root vulnerability that could have been avoided by
changing a few options in the configuration? Yes, they did. Fact.
What more do you want?
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69756/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On fredagen den 9 augusti 2002 12.48 Vincent Danen wrote: On Fri Aug 02, 2002 at 01:33:08PM +0400, Borsenkow Andrej wrote: [...] The last problem _was_ with privsep disabled. It still does not work. Sorry to ask but have you tested it? Chage user, set password change time in the past and try to log in (using public key as in my case). Yup, you're absolutely right. The way privsep is written changes the way the whole pam interaction is done. Unfortunately, there is no easy way around this except to downgrade to a pre-3.3p1 version. =( Or perhaps just ignore the privsep bsd shit and continue as before?, the huge security hole is gone anyway... Ignore privsep and move on, or turn mandrake into bsd? -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] sshd - cannot change expired password/no user login
--- Vincent Danen [EMAIL PROTECTED] wrote: Why not refer to this? Is not the openbsd FTP site running on openbsd? Actually all the reports said it was (strangely) running Solaris, which is a POS for security. If that's true, it blows half your argument, although I still agree with you. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: [Cooker] sshd - cannot change expired password/no user login
On Fri Aug 09, 2002 at 10:43:23AM -0700, David Walser wrote:
Why not refer to this? Is not the openbsd FTP site
running on
openbsd?
Actually all the reports said it was (strangely)
running Solaris, which is a POS for security. If
that's true, it blows half your argument, although I
still agree with you.
Ok, blows have my argument away but strengthens my argument that the
openbsd team really don't know what they're doing.
Why they would put their primary FTP site on Solaris when openbsd runs
just peachy on sparc is beyond me. That's just plain stupid.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69792/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Fri Aug 09, 2002 at 07:33:09PM -0400, Oden Eriksson wrote:
[...]
The last problem _was_ with privsep disabled. It still does not work.
Sorry to ask but have you tested it? Chage user, set password change
time in the past and try to log in (using public key as in my case).
Yup, you're absolutely right. The way privsep is written changes the
way the whole pam interaction is done.
Unfortunately, there is no easy way around this except to downgrade to
a pre-3.3p1 version. =(
Or perhaps just ignore the privsep bsd shit and continue as before?, the huge
security hole is gone anyway...
That's the problem.. you can't. Disabling privsep doesn't remove it
from the code. The introduction of privsep changed some of the
fundamental code in openssh; as it's been pointed out before, password
aging just doesn't work period in openssh right now, regardless of
whether privsep is enabled or not. So, to continue on as before,
would be to downgrade openssh to a pre-privsep version.
Ignore privsep and move on, or turn mandrake into bsd?
Can't ignore it. Hopefully in the future we can, and have everything
work as before. Better yet, I'm hoping privsep starts to work
properly and we don't have to ignore but can use it. I really like
the concept of privsep.. it's the implementation and the way this
whole mess came about that leaves a bitter taste in my mouth.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69794/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Fri, Aug 09, 2002 at 02:25:11PM -0600, Vincent Danen wrote: Ok, blows have my argument away but strengthens my argument that the openbsd team really don't know what they're doing. Why they would put their primary FTP site on Solaris when openbsd runs just peachy on sparc is beyond me. That's just plain stupid. It's quite possible that their ftp site is hosted by someone else who is donating hardware and bandwidth. Beggars can't be choosers. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
RE: [Cooker] sshd - cannot change expired password/no user login
On Thu Aug 01, 2002 at 03:16:35PM +0200, Oden Eriksson wrote: [...] Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. True, and this has been discussed earlier IIRC. Unfortunately disabling privsep still does not wotk. Now it fails differently but still fails, at lest when using the same openssh client version. May be there is something else that must be changed? Hmmm, I thought this was only a server side thing... Does your sshd_config look like this UsePrivilegeSeparation no on the server, and (silly question) have you restarted the sshd (stop|start)?. Right. privsep is only useful server-side. I have disabled it on server side. And I have restarted server after it. With privsep enabled it fails differently (just closes connection with different messages logged). [...] Right. With privsep disabled, sshd will do all the pam stuff as root which should work just as it always did. The last problem _was_ with privsep disabled. It still does not work. Sorry to ask but have you tested it? Chage user, set password change time in the past and try to log in (using public key as in my case). -andrej
Re: [Cooker] sshd - cannot change expired password/no user login
On Fridayen den 2 August 2002 11.33, Borsenkow Andrej wrote: On Thu Aug 01, 2002 at 03:16:35PM +0200, Oden Eriksson wrote: [...] Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. True, and this has been discussed earlier IIRC. Unfortunately disabling privsep still does not wotk. Now it fails differently but still fails, at lest when using the same openssh client version. May be there is something else that must be changed? Hmmm, I thought this was only a server side thing... Does your sshd_config look like this UsePrivilegeSeparation no on the server, and (silly question) have you restarted the sshd (stop|start)?. Right. privsep is only useful server-side. I have disabled it on server side. And I have restarted server after it. With privsep enabled it fails differently (just closes connection with different messages logged). What happens if you compile the client without privsep? -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
RE: [Cooker] sshd - cannot change expired password/no user login
I have disabled it on server side. And I have restarted server after it. With privsep enabled it fails differently (just closes connection with different messages logged). What happens if you compile the client without privsep? Unfortunately, I have really no time to test it in near future. Sorry :(
Re: [Cooker] sshd - cannot change expired password/no user login
On Fridayen den 2 August 2002 12.19, Borsenkow Andrej wrote: I have disabled it on server side. And I have restarted server after it. With privsep enabled it fails differently (just closes connection with different messages logged). What happens if you compile the client without privsep? Unfortunately, I have really no time to test it in near future. Sorry :( I do, I'm curious. Is it ML8.2? -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
RE: [Cooker] sshd - cannot change expired password/no user login
On Fridayen den 2 August 2002 12.19, Borsenkow Andrej wrote: I have disabled it on server side. And I have restarted server after it. With privsep enabled it fails differently (just closes connection with different messages logged). What happens if you compile the client without privsep? Unfortunately, I have really no time to test it in near future. Sorry :( I do, I'm curious. Is it ML8.2? server was ML8.2 + most current updates, client was cooker (pretty outdated must I say). -andrej
Re: [Cooker] sshd - cannot change expired password/no user login
On Thursdayen den 1 August 2002 10.03, Borsenkow Andrej wrote: 20020426 - (djm) Disable PAM password expiry until a complete fix for bug #188 exists disable where? Disable privsep is another way to do it. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
RE: [Cooker] sshd - cannot change expired password/no user login
On Thursdayen den 1 August 2002 10.03, Borsenkow Andrej wrote: 20020426 - (djm) Disable PAM password expiry until a complete fix for bug #188 exists disable where? Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. -andrej
Re: [Cooker] sshd - cannot change expired password/no user login
On Thursdayen den 1 August 2002 13.02, Borsenkow Andrej wrote: On Thursdayen den 1 August 2002 10.03, Borsenkow Andrej wrote: 20020426 - (djm) Disable PAM password expiry until a complete fix for bug #188 exists disable where? Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. True, and this has been discussed earlier IIRC. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
RE: [Cooker] sshd - cannot change expired password/no user login
On Thursdayen den 1 August 2002 13.02, Borsenkow Andrej wrote: On Thursdayen den 1 August 2002 10.03, Borsenkow Andrej wrote: 20020426 - (djm) Disable PAM password expiry until a complete fix for bug #188 exists disable where? Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. True, and this has been discussed earlier IIRC. Unfortunately disabling privsep still does not wotk. Now it fails differently but still fails, at lest when using the same openssh client version. May be there is something else that must be changed? bor@cooker% ssh iap-pxy-mow1 Enter passphrase for key '/home/bor/.ssh/id_rsa': Enter passphrase for key '/home/bor/.ssh/id_dsa': bor@iap-pxy-mow1's password: Permission denied, please try again. bor@iap-pxy-mow1's password: Received disconnect from x.x.x.x: 2: Too many authentication failures for bor And on server host: Aug 1 15:56:31 iap-pxy-mow1 sshd[8282]: Could not reverse map address x.x.x.x. Aug 1 15:56:31 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:31 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:31 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:31 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:31 iap-pxy-mow1 sshd[8282]: Postponed publickey for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:33 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:33 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:33 iap-pxy-mow1 sshd[8282]: Failed publickey for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:33 iap-pxy-mow1 sshd[8282]: Postponed publickey for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:35 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:35 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:35 iap-pxy-mow1 sshd[8282]: Failed publickey for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:35 iap-pxy-mow1 sshd[8282]: Failed keyboard-interactive for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:37 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:37 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:37 iap-pxy-mow1 sshd[8282]: Failed password for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:39 iap-pxy-mow1 sshd(pam_unix)[8282]: account bor has expired (failed to change password) Aug 1 15:56:39 iap-pxy-mow1 sshd[8282]: PAM rejected by account configuration[13]: User account has expired Aug 1 15:56:39 iap-pxy-mow1 sshd[8282]: Failed password for bor from x.x.x.x port 1061 ssh2 Aug 1 15:56:39 iap-pxy-mow1 sshd[8282]: Disconnecting: Too many authentication failures for bor
Re: [Cooker] sshd - cannot change expired password/no user login
On Thursdayen den 1 August 2002 13.59, Borsenkow Andrej wrote: On Thursdayen den 1 August 2002 13.02, Borsenkow Andrej wrote: On Thursdayen den 1 August 2002 10.03, Borsenkow Andrej wrote: 20020426 - (djm) Disable PAM password expiry until a complete fix for bug #188 exists disable where? Disable privsep is another way to do it. that means that sshd in default installation has large bug. If privsep results in complete user lockout, then _PLEASE_ disable it by default. True, and this has been discussed earlier IIRC. Unfortunately disabling privsep still does not wotk. Now it fails differently but still fails, at lest when using the same openssh client version. May be there is something else that must be changed? Hmmm, I thought this was only a server side thing... Does your sshd_config look like this UsePrivilegeSeparation no on the server, and (silly question) have you restarted the sshd (stop|start)?. bor@cooker% ssh iap-pxy-mow1 Enter passphrase for key '/home/bor/.ssh/id_rsa': Enter passphrase for key '/home/bor/.ssh/id_dsa': bor@iap-pxy-mow1's password: Permission denied, please try again. bor@iap-pxy-mow1's password: Received disconnect from x.x.x.x: 2: Too many authentication failures for bor ssh -vvv is your friend. I think an ssh key login will override this, have you tried this? From what I know it doesn't help to pass any privsep stuff using the client. Well..., I don't know much about this other than one must keep away from passwd aging (or privsep) until the ssh pam bug is fixed. Sorry... -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] sshd - cannot change expired password/no user login
On Thu Aug 01, 2002 at 03:02:38PM +0400, Borsenkow Andrej wrote:
20020426
- (djm) Disable PAM password expiry until a complete fix for bug
#188
exists
disable where?
Disable privsep is another way to do it.
that means that sshd in default installation has large bug. If privsep
results in complete user lockout, then _PLEASE_ disable it by default.
There are some little quirks with privsep and pam due to how privsep
tries to do the authentication as a non-root user. As soon as a new
openssh comes out that fixes this, it will go into updates all over
the place.
I'm not comfortable with disabling privsep for a few reasons. For
one, it is extremely valuable... it's (to me) an essential feature.
And not everyone does password aging (which is the problem here).
I would rather have people disable privsep manually if they are using
password aging. Unless you know of a way to determine if password
aging is enabled on a system (so I can work some magic with the
%post scripts), I would rather leave privsep enabled.
Password aging is used more on servers than workstations, and one
would assume that a sysadmin would know how to edit sshd_config and
restart the ssh server.
As well, considering how badly the openbsd/openssh teams are fscking
things up these days, I think having privsep there is almost essential.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69268/pgp0.pgp
Description: PGP signature
Re: [Cooker] sshd - cannot change expired password/no user login
On Thu Aug 01, 2002 at 03:16:35PM +0200, Oden Eriksson wrote:
[...]
Disable privsep is another way to do it.
that means that sshd in default installation has large bug. If
privsep
results in complete user lockout, then _PLEASE_ disable it by
default.
True, and this has been discussed earlier IIRC.
Unfortunately disabling privsep still does not wotk. Now it fails
differently but still fails, at lest when using the same openssh client
version. May be there is something else that must be changed?
Hmmm, I thought this was only a server side thing... Does your sshd_config
look like this UsePrivilegeSeparation no on the server, and (silly
question) have you restarted the sshd (stop|start)?.
Right. privsep is only useful server-side.
bor@cooker% ssh iap-pxy-mow1
Enter passphrase for key '/home/bor/.ssh/id_rsa':
Enter passphrase for key '/home/bor/.ssh/id_dsa':
bor@iap-pxy-mow1's password:
Permission denied, please try again.
bor@iap-pxy-mow1's password:
Received disconnect from x.x.x.x: 2: Too many authentication failures
for bor
ssh -vvv is your friend. I think an ssh key login will override this, have
you tried this?
IIRC, no it won't. ssh keys and password auth still use the same code
as far as PAM is concerned (PAM is trying to determine if the user has
credentials to login; doesn't really matter about the password stuff).
The problem is that when privsep does it's authentication, it is
running as the sshd user with no privs. pam doesn't really like
this. And especially not when a password change is required.
I'll see what I can come up with after I finish rebuilding openssl for
updates with the ASN.1 fix (that is top priority). Once I've done
that, I'll see what I can do about this.
From what I know it doesn't help to pass any privsep stuff using the client.
Well..., I don't know much about this other than one must keep away from
passwd aging (or privsep) until the ssh pam bug is fixed. Sorry...
Right. With privsep disabled, sshd will do all the pam stuff as root
which should work just as it always did.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import
{GnuPG: 1024D/FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg69269/pgp0.pgp
Description: PGP signature
