my previous hostname used to be 123-234-321-123-some.cal.isp.net.example, which I set with hostname -s remote.location.example456.com, because it was obnoxious to see such a long name. That solves the value of $echo hostname which now returns remote.location.example456.com.

Mac OS X, 10.6 is this case, does seem to honor:

touch ~/.hushlogin

If leave that file empty, I get nothing on the shell when I login. I want to know what controls the host resolution of the IP, and how it is all working. For example, running last reports a huge list of my logins, which have obtusely long hostnames, when they would be preferable to just be remote.location.example456.com.

More confusing to me, reading the man page for wtmp and lastlog, it looks like lastlog is not used on OS X, /var/log/lastlog does not exist. Actually, none of these exist on 10.5 or 10.6:

2 Answers
2

The man pages on my 10.6 machine point me in the direction of asl(3), utmpx(5), and endutxent(3). It seems modern Mac OS X records utmp/wtmp/lastlog-like information in the Apple SysLog (asl) database files at /var/log/asl/*.

It seems the long hostnames that bother you were recorded in that database back when that was what those hosts were named, and you can't get rid of them short of pruning or editing your asl database.

Ahh, this is very good, I am happy to wipe the asl database, and you are right, at one time, I did not have PTR's set, so they got into the ASL db, and are not "stuck" that way. Thanks. This sucks, because you and the other guys are both right on in your answers, which one do I check off?
–
user17245Apr 8 '10 at 23:21

PrintLastLog
Specifies whether sshd(8) should print the date and time of the
last user login when a user logs in interactively. The default
is ``yes''.

So that at least explains why you're seeing the message.

regarding the hostname resolution - it will use the system resolver library, which may return different results than dig. In particular, if you have an entry in your local (ie, local to the remote machine) /etc/hosts file, that will (probably, depending on how the resolver is configured) be checked first. If the remote machine is using a local (to it) nameserver that servers a different result than the public result (eg, your ISP serves one set of PTR records internally and another set externally) this could also explain the disparity.

I checked off the other answer as correct, as it tell me how to fix the hostname, but you also tell me how to change the LastLog bits, so I wanted to check you off. It ended up being a matter of what was most important to me to solve. Thank you, your answer was spot on as well.
–
user17245Apr 8 '10 at 23:22