Mailing List Archive

anomalous wtmp logging bug
I've noticed rather strange wtmp logging behavior in sshd. Can anyone
confirm or solve the following:

Once a user authenticates themself to sshd, sshd among other things
records the login in the wtmp, which `last` reads. However, sshd logs
hostnames which are longer than 16 characters instead of IPs like normal
programs would. As a result, I have useless entries such as:

tempest ttyp4 1cust126.tnt5.ta Sat Mar 11 22:33 - 14:03
(15:29)

which there is no way of telling what IP that was from.

One option I found using was the UseLogin option, where openssh
authenticates via login(1). This would work correctly but the wtmp
logging was awkward:

tempest ttyp4 63.10.229.126 Sat Mar 11 22:33 - 14:03
(15:29)
tempest ttyp4 1cust126.tnt5.ta Sat Mar 11 22:33 still logged
in

Instead of only login(1) making the entry, both login(1) and sshd did,
however login(1) logged it correctly (via only the IP) but sshd also
logged it, incorrectly, and didn't 'log the user off' properly.

How can i make sshd log via ONLY login(1) w/o sshd re-logging the event,
OR How can i make sshd do the logging properly (not logging hostnames that
get cut off). The OpenSSH version I'm working with is 1.2.2 on a FreeBSD
system. Thanks in advance.

Regards,
Alex
Re: anomalous wtmp logging bug [ In reply to ]
On Fri, 31 Mar 2000, Alex wrote:

>
> I've noticed rather strange wtmp logging behavior in sshd. Can anyone
> confirm or solve the following:
>
> Once a user authenticates themself to sshd, sshd among other things
> records the login in the wtmp, which `last` reads. However, sshd
> logs hostnames which are longer than 16 characters instead of IPs
> like normal programs would. As a result, I have useless entries
> such as:

OpenSSH logs both hostname and IP address if you wtmp supports it.
Under RedHat Linux I can get the IP addresses using "last -i". If
you would prefer IP addresses being logged instead of hostname,
you may want to hack on login.c. grep for ut_host and ut_addr.

-d

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)
Re: anomalous wtmp logging bug [ In reply to ]
On Fri, 31 Mar 2000, Damien Miller wrote:

> On Fri, 31 Mar 2000, Alex wrote:
>
> >
> > I've noticed rather strange wtmp logging behavior in sshd. Can anyone
> > confirm or solve the following:
> >
> > Once a user authenticates themself to sshd, sshd among other things
> > records the login in the wtmp, which `last` reads. However, sshd
> > logs hostnames which are longer than 16 characters instead of IPs
> > like normal programs would. As a result, I have useless entries
> > such as:
>

Thanks for the speedy answer. I remember posting before with no reply,
I'm glad my cries are finally heard :-)

> OpenSSH logs both hostname and IP address if you wtmp supports it.
> Under RedHat Linux I can get the IP addresses using "last -i". If
> you would prefer IP addresses being logged instead of hostname,
> you may want to hack on login.c. grep for ut_host and ut_addr.

I forgot to mention the system; It's a FreeBSD system (i've upgraded it
to 4.0 from 3.3 recently, but it behaved like this already). I checked
the man page for 'last' and there is no option to see the IP. I assume
my wtmp logging setup doesn't support dual IP/hostname logging. A
suggestion I have is an option to detect that and/or a configure --option
to build sshd appropriately.

In the mean time, can you suggest what changes should be made to the
source to have sshd build so that it doesn't log when Login(1) is used?
Either that or have sshd log the IP if the hostname is longer than 16
chars (probably defined in wtmp.h though).

A patch would be much more helpful (not to mention appreciated). I dont
trust myself with modifying the source enough to post one myself.

Thanks.

>
> -d
>
> --
> | "Bombay is 250ms from New York in the new world order" - Alan Cox
> | Damien Miller - http://www.mindrot.org/
> | Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)
>
>
>
>
>