I've been running OpenSSH for quite some time now, and I have been acting more as the point man in making the builds for LinuxPPC as well as distributing it to the Linux for the PowerPC community. Things have worked rather well, making it a straight rebuild of the package. However, a new problem was introduced with 2.1.1p1. It's not critical, but a little more than a simple annoyance. For some reason, now, running 2.1.1p1, the timestamp in wtmp is always Dec 31 19:00. So, for example, if you type "who" or "last", those users who have logged in via ssh are listed as logging into the system on Dec 31 as well as having been logged in for a heck of a long time. :) Backing down to the previous port, 2.1.0p2, restored the system back to a fully functioning state. I went through this on two separate boxes with the same results... Not knowing just how to solve this, I thought I would send it into the list in the hopes that either (1) it was a known issue and being addressed or (2) it was not a known issue and will be addressed. :) Either way, thanks! -Rich -- Richard West mailto:richard.west at divatv.com Sr. Systems Administrator DivaTV Systems - Princeton, NJ http://www.divatv.com
The problem you are seeing can be solved by applying the patch which I submitted a week or so ago regarding the utmp login reporting on linux. You can get it from the list archives or let me know and I'll send it to you directly. Regards, Garrick P.S. Damien released a test bundle with the patch included, but I do not remember where to find it. On Mon, 26 Jun 2000, Richard West wrote:> I've been running OpenSSH for quite some time now, and I have been > acting more as the point man in making the builds for LinuxPPC as well > as distributing it to the Linux for the PowerPC community. > > Things have worked rather well, making it a straight rebuild of the > package. However, a new problem was introduced with 2.1.1p1. It's not > critical, but a little more than a simple annoyance. > > For some reason, now, running 2.1.1p1, the timestamp in wtmp is always > Dec 31 19:00. So, for example, if you type "who" or "last", those users > who have logged in via ssh are listed as logging into the system on Dec > 31 as well as having been logged in for a heck of a long time. :) > > Backing down to the previous port, 2.1.0p2, restored the system back to > a fully functioning state. I went through this on two separate boxes > with the same results... > > Not knowing just how to solve this, I thought I would send it into the > list in the hopes that either (1) it was a known issue and being > addressed or (2) it was not a known issue and will be addressed. :) > > Either way, thanks! > > -Rich > > > -- > Richard West mailto:richard.west at divatv.com > Sr. Systems Administrator > DivaTV Systems - Princeton, NJ http://www.divatv.com > > > > >
On Mon, 26 Jun 2000, Richard West wrote:> I've been running OpenSSH for quite some time now, and I have been > acting more as the point man in making the builds for LinuxPPC as well > as distributing it to the Linux for the PowerPC community.There is a problem with the current configure script when run under bash2. You might want to try: http://www.mindrot.org/misc/junk/openssh-SNAP-2000062600.tar.gz There is still one other problem with Slackware that I am tracking down. Regards, Damien Miller -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work)
openssh-SNAP-20000916.tar.gz compiled and tested okay on x86 SuSE 6.4 w/
OpenSSL-0.9.6-beta1 and the following options:
OpenSSH configured has been configured with the following options.
User binaries: /usr/local/bin
System binaries: /usr/local/sbin
Configuration files: /usr/local/etc
Askpass program: /usr/local/libexec/ssh/ssh-askpass
Manual pages: /usr/local/man/manX
PID file: /var/run
Random number collection: Device (/dev/urandom)
Manpage format: man
PAM support: yes
KerberosIV support: no
AFS support: no
S/KEY support: no
TCP Wrappers support: yes
MD5 password support: yes
IP address in $DISPLAY hack: no
Use IPv4 by default hack: yes
Translate v4 in v6 hack: yes
Compiler flags: -g -O2 -Wall -I/usr/local/ssl/include
Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl
Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto -lwrap
---
Daniel T. Chen | chenda at cs.unc.edu
On Sat, Sep 16, 2000 at 04:34:23AM -0400, Daniel T. Chen wrote:> openssh-SNAP-20000916.tar.gz compiled and tested okay on x86 SuSE 6.4 w/ > OpenSSL-0.9.6-beta1 and the following options:Did you test with the SSH-2 protocol? It should fail because of a problem that is actually being investigated. This does not affect the "stable" OpenSSL-0.9.5a release. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
Lutz, Yes, it failed for SSH-2 with "dsa_verify failed for server_host_key". Thanks for the heads up. dtc --- Daniel T. Chen | chenda at cs.unc.edu On Sat, 16 Sep 2000, Lutz Jaenicke wrote:> On Sat, Sep 16, 2000 at 04:34:23AM -0400, Daniel T. Chen wrote: > > openssh-SNAP-20000916.tar.gz compiled and tested okay on x86 SuSE 6.4 w/ > > OpenSSL-0.9.6-beta1 and the following options: > > Did you test with the SSH-2 protocol? It should fail because of a problem > that is actually being investigated. > This does not affect the "stable" OpenSSL-0.9.5a release. > > Best regards, > Lutz >