Home / server / Questions / 43104
Accepted
user1686
Asked: 2009-07-21 09:58:07 +0800 CST

Old utmp entries

  • 772

I'm an administrator of a small Debian Lenny server, and I have this problem: Sometimes, when a user's SSH session is closed, the entry is not removed from /var/run/utmp, resulting in such messages from finger:

grawity@sine ~$ finger
finger: /dev//pts/31: No such file or directory
Login        Name              Tty      Idle  Login Time   Office     Office Phone
user1        (user)            pts/1      1d  Jul 15 19:12 (foo.uk)
user2        (another user)    pts/33   6:25  Jul 13 12:02 (bar:S.1)
user2        (another user)   *pts/34   6:31  Jul 13 17:00 (bar:S.0)
grawity      (me)              pts/25         Jul 17 11:57 (78-56-197-6:S.0)
grawity      (me)              pts/27         Jul 17 11:57 (78-56-197-6.static.zebra.lt)
Segmentation fault
grawity@sine ~$ _

...and sometimes even a segfault or two. Once utmp even had two entries pointing to the same tty (but belonging to different users).

Any ideas why this happens?

So far, I manage to fix utmp (using some utility designed for erasing Unix logs :> ), but that is obviously not a solution, not when it happens every day.

Edit: This question is not about records disappearing (so far I haven't seen that) - it's about the opposite: records not being removed when a login session is closed.

linux log-files ssh

3 Answers

  1. Best Answer

    finger segfaulting is really not a good sign. I'd at least make cursory checks for break in; at least run chkrootkit and debsums for example. Second, have you tried clearing out utmp entirely by rm or echo -n > utmp? It may be corrupted in some subtle manner.

    Lastly, have you done anything with your PAM setup in /etc/pam.d? That could easily cause logouts not to be recorded.

    • 2

  2. Is owner of utmp file root:utmp and permissions 664?

    If permissions are fine and this is public server and ssh access on public interface is enabled then it could be due to break-in. No attacker would want you to know that he logged in, so it makes sense to modify utmp, btmp and wtmp files. If this is the case change root password, look for root-kits / open ports, setup very strict firewall, disable direct root login using SSH, install denyhosts, etc. But it could just be me being paranoid. I have just analyzed one break-in attempt so far and I did observer attackers deleting / modifying btmp and wtmp entries. I guess they do same to utmp entries too.

    • 0

  3. Are the faulty entries somehow related to specific users or their actions? Are these just regular ssh logins or do you use X11? Could you check if those 'phantom users' still have some processes running? If you are root, a look at their .bash_history will give at least some idea what they are doing.

    Just to be paranoid, I would probably also run fsck. Checking for signs of rootkits etc seems like a good idea also.

    • 0