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 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 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 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 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 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 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 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
--- 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 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
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 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 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 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
> > 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 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
> > 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 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
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 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 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.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 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 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