5

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.

Improve this question
2
  • Do you have UseLogin or UsePAM enabled in /etc/ssh/sshd_config ?
    – Kamil Kisiel
    Jul 21, 2009 at 6:38
  • UsePAM is enabled (the server uses Kerberos and LDAP authentication). UseLogin is commented out, but it defaults to no.
    – u1686_grawity
    Jul 21, 2009 at 12:45

3 Answers 3

Reset to default
2

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.

Improve this answer
1
  • PAM is configured to check logins against a Kerberos server, but the same configuration is used on other servers too. Finger segfaults only sometimes, and only until I manually remove the old entries. I haven't tried clearing utmp, as I don't want to accidentially create a huge mess.
    – u1686_grawity
    Jul 22, 2009 at 7:19
0

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.

Improve this answer
2
  • 1
    Yes, the permissions are correct. But this is not the case of disappearing entries - my problem is entries not being deleted when they're supposed to be (such as a closed SSH session).
    – u1686_grawity
    Jul 21, 2009 at 6:28
  • If some one tries to delete their own entries from utmp using their own programs, then, utmp file which is also open by login program might get damaged. In that case contents of utmp can get garbled and hence SSH is not able to remove the login information when user logs out. This is again just a possibility, there can offcourse be some other totally different reason for the problem.
    – Saurabh Barjatiya
    Jul 21, 2009 at 6:42
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .