Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Do you have UseLogin or UsePAM enabled in /etc/ssh/sshd_config ? –  Kamil Kisiel Jul 21 '09 at 6:38
    
UsePAM is enabled (the server uses Kerberos and LDAP authentication). UseLogin is commented out, but it defaults to no. –  grawity Jul 21 '09 at 12:45
add comment

3 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
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. –  grawity Jul 22 '09 at 7:19
add comment

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.

share|improve this answer
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). –  grawity Jul 21 '09 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 '09 at 6:42
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.