I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works correctly and the entry in the logfile is: Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from 192.38.97.131 port 2463 Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not accept the password any more and the entries in the logfile are: Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is locked Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from 130.225.127.34 port 50593 ssh2 Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs from 130.225.127.34 port 50593 ssh2 The /etc/sshd_config is the same in the two cases. Jan P. Sorensen
Jan P. Sorensen wrote:> I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works > correctly and the entry in the logfile is: > > Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from > 192.38.97.131 port 2463 > > Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not > accept the password any more and the entries in the logfile are: > > Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is > locked > Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from > 130.225.127.34 port 50593 ssh2 > Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs > from 130.225.127.34 port 50593 ssh2 > > The /etc/sshd_config is the same in the two cases.May I guess it is because PAM has been disabled, and you are running ShadowPassword on 11.11? Non-PAM password authentication is not able to pickup shadow passwords, because this is disabled, too. (See also http://bugzilla.mindrot.org/show_bug.cgi?id=633) Cheers! Michael
"Jan P. Sorensen" wrote:> > I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works > correctly and the entry in the logfile is: > > Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from > 192.38.97.131 port 2463 > > Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not > accept the password any more and the entries in the logfile are: > > Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is > locked > Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from > 130.225.127.34 port 50593 ssh2 > Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs > from 130.225.127.34 port 50593 ssh2Is that box in trusted mode? Does this help: http://bugzilla.mindrot.org/show_bug.cgi?id=633 -- 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.
Yes, HP-UX is run in trusted mode. Notice that the problem first appeared today when I upgraded from p1 to p2. Jan P. Sorensen On Wed, 24 Sep 2003, Darren Tucker wrote:> "Jan P. Sorensen" wrote: > > > > I have used SSHD from openssh-3.7.1p1 on HP-UX 11:11. It works > > correctly and the entry in the logfile is: > > > > Sep 24 07:01:20 garm sshd[6625]: Accepted password for japs from > > 192.38.97.131 port 2463 > > > > Next I have upgraded to openssh-3.7.1p2 and restarted SSHD. It does not > > accept the password any more and the entries in the logfile are: > > > > Sep 24 12:21:38 garm sshd[19542]: User japs not allowed because account is > > locked > > Sep 24 12:21:38 garm sshd[19542]: Failed none for illegal user japs from > > 130.225.127.34 port 50593 ssh2 > > Sep 24 12:21:41 garm sshd[19542]: Failed password for illegal user japs > > from 130.225.127.34 port 50593 ssh2 > > Is that box in trusted mode? Does this help: > http://bugzilla.mindrot.org/show_bug.cgi?id=633 > > -- > 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. >
Jan P. Sorensen wrote:> Yes, HP-UX is run in trusted mode. > > Notice that the problem first appeared today when I upgraded from p1 to > p2.The relevant difference is that p1 had PAM enabled by default, while it was disabled in p2. So it refers to non-PAM password authentication, which is broken in both for trusted systems and those using shadow passwords. Does http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view fix it? Alternatively, you may explicitly enable PAM in sshd_config and contemplate about whether this is secure or not... Cheers! Michael
Michael Steffens wrote:> Jan P. Sorensen wrote: > >> Yes, HP-UX is run in trusted mode. >> >> Notice that the problem first appeared today when I upgraded from p1 to >> p2. > > > The relevant difference is that p1 had PAM enabled by default, while > it was disabled in p2. > > So it refers to non-PAM password authentication, which is broken > in both for trusted systems and those using shadow passwords. > > Does > > http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view > > fix it?Sorry, the patch above is against CVS version and needs autoconf and autoheader to be run before configure. In order to achieve the same result in release version without these tools you may comment out or remove #define DISABLE_SHADOW in config.h after running configure. Then apply the patch above concerning openbsd-compat/xcrypt.c
I have tried the two changes but the login/password continues to fail. Jan p. Sorensen On Wed, 24 Sep 2003, Michael Steffens wrote:> Michael Steffens wrote: > > Jan P. Sorensen wrote: > > > >> Yes, HP-UX is run in trusted mode. > >> > >> Notice that the problem first appeared today when I upgraded from p1 to > >> p2. > > > > > > The relevant difference is that p1 had PAM enabled by default, while > > it was disabled in p2. > > > > So it refers to non-PAM password authentication, which is broken > > in both for trusted systems and those using shadow passwords. > > > > Does > > > > http://bugzilla.mindrot.org/attachment.cgi?id=386&action=view > > > > fix it? > > Sorry, the patch above is against CVS version and needs autoconf > and autoheader to be run before configure. > > In order to achieve the same result in release version without these > tools you may comment out or remove > > #define DISABLE_SHADOW > > in config.h after running configure. Then apply the patch above > concerning openbsd-compat/xcrypt.c > > >
Jan P. Sorensen wrote:> I have tried the two changes but the login/password continues to fail.I have attached a patch against 3.7.1p2, which worked for me in trusted and non-trusted mode, including long passwords in trusted mode, with and without privsep, both proto 1 and 2. Does that help? Cheers! Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hpux-shadow.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030925/809b0ddb/attachment.ksh
No, it did not help. Jan p. Sorensen On Thu, 25 Sep 2003, Michael Steffens wrote:> Jan P. Sorensen wrote: > > I have tried the two changes but the login/password continues to fail. > > I have attached a patch against 3.7.1p2, which worked for me in trusted > and non-trusted mode, including long passwords in trusted mode, with and > without privsep, both proto 1 and 2. > > Does that help? > > Cheers! > Michael >
Jan P. Sorensen wrote:> No, it did not help. > > Jan p. Sorensen > > On Thu, 25 Sep 2003, Michael Steffens wrote: > > >>Jan P. Sorensen wrote: >> >>>I have tried the two changes but the login/password continues to fail. >> >>I have attached a patch against 3.7.1p2, which worked for me in trusted >>and non-trusted mode, including long passwords in trusted mode, with and >>without privsep, both proto 1 and 2. >> >>Does that help?Did it change anything about the failures? What does syslog report now? What does sshd report in debugging mode? Cheers! Michael
Michael Steffens wrote:> Jan P. Sorensen wrote: > >> No, it did not help. >> >> Jan p. Sorensen >> >> On Thu, 25 Sep 2003, Michael Steffens wrote: >> >> >>> Jan P. Sorensen wrote: >>> >>>> I have tried the two changes but the login/password continues to fail. >>> >>> >>> I have attached a patch against 3.7.1p2, which worked for me in trusted >>> and non-trusted mode, including long passwords in trusted mode, with and >>> without privsep, both proto 1 and 2. >>> >>> Does that help? > > > Did it change anything about the failures? What does syslog report now? > What does sshd report in debugging mode?Further possibilty: When testing do you toggle sshd versions or trusted mode? In case you do the latter, did you change user passwords after converting to trusted mode? Cheers! Michael
When I applied the patches/mods to openssh-3.7.1p2/configure and openbsd-compat/xcrypt.c password authentication still fails, though differently from the "account is locked" message. syslog now reports: User eric password has expired (password aged) Failed none for illegal user eric from 128.128.64.78 port 53132 ssh2 Failed password for illegal user eric from 128.128.64.78 port 53132 ssh2 Needless to say, the password hasn't expired. ============================================================ Eric Cunningham Computer and Information Services - http://www.whoi.edu/CIS Woods Hole Oceanographic Institution - http://www.whoi.edu Woods Hole, MA 02543-1541 phone: (508) 289-2224 fax: (508) 457-2174 e-mail: ecunningham at whoi.edu =============================================================
Hi All.
Attached is a smallish patch against -current to prevent the
expires-every-day behaviour on Trusted HP-UX systems. Credit goes to
Micheal for figuring this one out.
That section of code will need to be tidied up when the password expiry
patches go in anyway, currently I'm interested in making the snapshots
work for people using HP-UX. Is this patch OK until then?
For those of you using 3.7.1p2 on HP-UX, I have a patch that contains
only HP-UX fixes against 3.7.1p2. It patches configure too so you don't
need autoconf, just apply it to 3.7.1p2 and you should be good to go.
http://www.zip.com.au/~dtucker/openssh/openssh-3.7.1p2-hpux.patch
--
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.
-------------- next part --------------
Index: auth.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v
retrieving revision 1.78
diff -u -p -r1.78 auth.c
--- auth.c 2 Oct 2003 06:12:36 -0000 1.78
+++ auth.c 7 Oct 2003 05:42:42 -0000
@@ -90,6 +90,7 @@ allowed_user(struct passwd * pw)
#ifdef HAS_SHADOW_EXPIRE
#define DAY (24L * 60 * 60) /* 1 day in seconds */
if (!options.use_pam && spw != NULL) {
+ int disabled = 0;
time_t today;
today = time(NULL) / DAY;
@@ -106,13 +107,19 @@ allowed_user(struct passwd * pw)
return 0;
}
- if (spw->sp_lstchg == 0) {
+#if defined(__hpux) && !defined(HAVE_SECUREWARE)
+ if (iscomsec() && spw->sp_min == 0 && spw->sp_max == 0
&&
+ spw->sp_warn == 0)
+ disabled = 1; /* Trusted Mode: expiry disabled */
+#endif
+
+ if (!disabled && spw->sp_lstchg == 0) {
logit("User %.100s password has expired (root forced)",
pw->pw_name);
return 0;
}
- if (spw->sp_max != -1 &&
+ if (!disabled && spw->sp_max != -1 && spw->sp_max != 0
&&
today > spw->sp_lstchg + spw->sp_max) {
logit("User %.100s password has expired (password aged)",
pw->pw_name);