Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' required. *WHAT* other issues *MUST* be address before 3.0 which is approaching fast? Those running NeXTStep I need conformation that it works under NeXT. My current Slab is packed in a storage unit due to a fire in my apartment complex (happened above me so I'm wrapping up dealing with that crap =). - Ben
On Tue, Oct 23, 2001 at 11:25:52AM -0500, mouring at etoh.eviladmin.org wrote:> > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' > required. *WHAT* other issues *MUST* be address before 3.0 which is > approaching fast?I think my patches for expiring shadow passwords and for host key size mismatch are the highest priority of the patches I've submitted, and should be put in 3.0. They will save a lot of people a lot of trouble. Also, if you want to it to compile on Sunos4 you need my openbsd-compat/readpassphrase.c patch. - Dave Dykstra
On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:> *WHAT* other issues *MUST* be address before 3.0 which is > approaching fast?I would greatly appreciate it if you'd apply this patch that I first submitted back in April: Index: loginrec.c --- loginrec.c 2001/10/22 06:49:23 1.36 +++ loginrec.c 2001/10/23 19:22:17 @@ -448,6 +448,8 @@ login_utmp_only(struct logininfo *li) { li->type = LTYPE_LOGIN; + /* set the timestamp */ + login_set_current_time(li); # ifdef USE_UTMP utmp_write_entry(li); # endif It sets the time in the logininfo structure so that the "last" log doesn't get an event with a timestamp of Dec 31, 1969. This patch only affects the LOGIN_NEEDS_UTMPX code path. ..wayne..
Is the problem with clear-text passwords after using the kludge on Sol8 known and will it be fixed ? I didn't see any reply on this problem. - Alex> -----Original Message----- > From: mouring at etoh.eviladmin.org [SMTP:mouring at etoh.eviladmin.org] > Sent: Tuesday, October 23, 2001 18:26 > To: openssh-unix-dev at mindrot.org > Subject: Another round of testing calls. > > > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' > required. *WHAT* other issues *MUST* be address before 3.0 which is > approaching fast? > > Those running NeXTStep I need conformation that it works under NeXT. My > current Slab is packed in a storage unit due to a fire in my apartment > complex (happened above me so I'm wrapping up dealing with that crap =). > > - Ben
I compiled OpenSSH 2.9.9p2 on solaris 8 --with-pam --with-tcp-wrappers The PAM_TTY_KLUDGE was needed so that password expiration check was done. But after the message 'password expired, please enter login password', the pasword now typed is clear-text and not hidden on the screen. Furthermore on my system the changing of the password failed with a message of something about removing root credentials and breaking secure rpc... I posted a message recently with the screenshot of this message. (expired password problems... from Oct 29, 09:24 number 122 on the web-page). Alex> -----Original Message----- > From: Ed Phillips [SMTP:ed at UDel.Edu] > Sent: Wednesday, October 24, 2001 15:27 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: RE: Another round of testing calls. > > On Wed, 24 Oct 2001, Dost, Alexander wrote: > > > Date: Wed, 24 Oct 2001 10:46:57 +0200 > > From: "Dost, Alexander" <Alexander.Dost at drkw.com> > > To: openssh-unix-dev at mindrot.org > > Subject: RE: Another round of testing calls. > > > > Is the problem with clear-text passwords after using the kludge on Sol8 > > known and will it be fixed ? > > I didn't see any reply on this problem. > > What problem do you mean? > > Thanks, > > Ed > > > > > - Alex > > > > > -----Original Message----- > > > From: mouring at etoh.eviladmin.org [SMTP:mouring at etoh.eviladmin.org] > > > Sent: Tuesday, October 23, 2001 18:26 > > > To: openssh-unix-dev at mindrot.org > > > Subject: Another round of testing calls. > > > > > > > > > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' > > > required. *WHAT* other issues *MUST* be address before 3.0 which is > > > approaching fast? > > > > > > Those running NeXTStep I need conformation that it works under NeXT. > My > > > current Slab is packed in a storage unit due to a fire in my apartment > > > complex (happened above me so I'm wrapping up dealing with that crap > =). > > > > > > - Ben > > > > Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key
On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:> Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' > required. *WHAT* other issues *MUST* be address before 3.0 which is > approaching fast?I'm not saying MUST, but I've been trying to suggest a few modifications (under the OpenSSL_free thread) to contrib/redhat/openssh.spec for some time now. I've yet to receive a reply. Here's a full diff. It does: 1) As sshd -t is used when restarting sshd with RH scripts now, sshd_config is better marked with noreplace as all config files should. 2) '--with-ipv4-default' is removed; it's a major release after all. I haven't noticed any problems with this (and a lot of Linux distros already do it, including Red Hat), and if you'd have to run 'sshd -6', IPv4 port forwarding through mapped addresses won't work. Caveat: if you haven't patched your tcp_wrappers for IPv6, and IPv6 is enabled with SSHD, and you have access controls, you won't be let in even with IPv4 (connections seem to originate from 0.0.0.0 vs. ::ffff:ipv4addr). I don't see this as a huge problem, as you have to have IPv6 enabled. E.g. RHL72 already has patched tcp_wrappers. 3) Building appears to rely on the existance of openssl >= 0.9.6 (OPENSSL_free function). Mark the requirement there. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------- next part -------------- Index: contrib/redhat/openssh.spec ==================================================================RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v retrieving revision 1.89 diff -u -r1.89 openssh.spec --- contrib/redhat/openssh.spec 2001/10/24 05:36:55 1.89 +++ contrib/redhat/openssh.spec 2001/10/24 19:07:22 @@ -52,7 +52,7 @@ Group: Applications/Internet BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot Obsoletes: ssh -BuildPreReq: perl, openssl-devel, tcp_wrappers +BuildPreReq: perl, openssl-devel >= 0.9.6, tcp_wrappers BuildPreReq: /bin/login, /usr/include/security/pam_appl.h BuildPreReq: rpm >= 3.0.5 %if ! %{no_x11_askpass} @@ -62,9 +62,9 @@ BuildPreReq: gnome-libs-devel %endif %if ! %{static_libcrypto} -PreReq: openssl >= 0.9.5a +PreReq: openssl >= 0.9.6 PreReq: openssl = %{exact_openssl_version} -Requires: openssl >= 0.9.5a +Requires: openssl >= 0.9.6 %endif Requires: rpm >= 3.0.5 @@ -155,7 +155,6 @@ --datadir=%{_datadir}/openssh \ --with-pam \ --with-tcp-wrappers \ - --with-ipv4-default \ --with-rsh=/usr/bin/rsh \ --with-default-path=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin \ $EXTRA_OPTS @@ -264,8 +263,7 @@ %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server %attr(0644,root,root) %{_mandir}/man8/sshd.8* %attr(0644,root,root) %{_mandir}/man8/sftp-server.8* -#%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config -%attr(0600,root,root) %config %{_sysconfdir}/sshd_config +%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd %attr(0755,root,root) %config /etc/rc.d/init.d/sshd
>How do you enforce PAM limits without opening a session then?pam_limits should probably be either an pam_acct_mgmt or pam_setid module. pam_limits doesn't exist on Solaris. Solaris does how ever have pam_projects which deals with setting resource control information for project(4). It isn't really clear from the man pages what the true purpose of pam_open_session is but it can be infered from the Solaris man pages that it is really about dealing with files like lastlog/utmpx/wtmpx. -- Darren J Moffat
>What is pam_setid? Do you mean pam_setcred? pam_setcred has always beenyes I meant setcred.>a little fuzzy... the pam_setcred from pam_unix.so has changed function >between Sol2.6 and Sol7. In 2.6, pam_sm_setcred did nothing and >initgroups() was called by login or other apps directly. In Sol7, >pam_sm_setcred actually called initgroups() and the apps were made >to call pam_setcred with expectations of it calling initgroups().That is not correct. The code for pam_sm_setcred in pam_unix hasn't actually changed between 2.6 and the current builds of the next release of Solaris. Well that isn't quite true there were a few minor changes but that was fixing a broken cast to remove a compiler warning and chaning the wording of one of the messages that prints it out. I've just checked the code (and BTW this is one of my areas of Solaris responsibility). The last time that initgroups didn't happen in the application but happened in the module was 2.5.1 - when PAM was in prerelease state and not configurable or public. Having said all of that what you were suggesting had happened is actually the correct way to go, initgroups probably should be called from the pam_unix pam_setcred and not the application since your supplementary groups are your unix creds. However we don't currently do that - if Solaris ever does get to that stage then OpenSSH should be updated to not do the initgroups calls if being built to run on that release of Solaris. -- Darren J Moffat
On Tue, 23 Oct 2001 mouring at etoh.eviladmin.org wrote:> Date: Tue, 23 Oct 2001 11:25:52 -0500 (CDT) > From: mouring at etoh.eviladmin.org > To: openssh-unix-dev at mindrot.org > Subject: Another round of testing calls. > > > Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' > required. *WHAT* other issues *MUST* be address before 3.0 which is > approaching fast? > > Those running NeXTStep I need conformation that it works under NeXT. My > current Slab is packed in a storage unit due to a fire in my apartment > complex (happened above me so I'm wrapping up dealing with that crap =). > > - Ben >Forgive me if this is stupid, but the following quote from WARNING.RNG made me wondering whether DSA/DSS could be disabled from SSH: A particularly pernicious problem arises with DSA keys (used by the ssh2 protocol). Performing a DSA signature (which is required for authentication), entails the use of a 160 bit random number. If an attacker can predict this number, then they can deduce your *private* key and impersonate you or your hosts. I am esp. worried about the systems without kernel supply of strong random numbers. So is it possible to disable all use of DSA, or does protocol v2 requires it? If it is possible, is that enough to set HostKeyAlgorithms to ssh-rsa alone on client, and remove dsa keys on server, or should we have a compile-time option to remove DSA code from ssh/sshd? Best regards, Wojtek -------------------- Wojtek Pilorz Wojtek.Pilorz at bdk.pl