Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

/var/log/btmp is the file that is supposed to contain all the bad login attempts (at least that was the case on Fedora). On my Debian GNU/Linux 5.0 server, it's empty. The permissions were originally:

-rw-rw---- 1 root utmp 0 Jul 1 06:25 /var/log/btmp

but I changed them to:

-rw------- 1 root root 0 Jul 1 06:25 /var/log/btmp

but that didn't work either. I'm still not seeing anything in btmp (and yes, I'm creating bad login attempts to test it).

I've Googled my brains out, but can't find a fix. Any ideas?

share|improve this question
I confirm this behaviour on a fully patched debian lenny amd64 and i686. It works as expected on centos. Odd, did not notice this before. Time to open a bug, I suppose. – natxo asenjo Jul 15 '10 at 17:58
My CentOS machine does this, too. I have set logrotate to rotate it, and have a sizable btmp.1, although btmp is 0 bytes. last -f btmp yields nothing, though last and last -f btmp.1 do. Very strange. – Paul Lammertsma Jul 27 '10 at 2:07
up vote 2 down vote accepted

I think this is a problem with openssh. I tested this on an Ubuntu system and bad ssh login attempts get logged to /var/log/auth.log but not to btmp. At the console, bad login attempts do go to btmp.

In Google searches, I'm seeing reports of this going back to 2006-2007.

share|improve this answer
Not what I wanted to hear. But I think you're right. – Matt Jul 16 '10 at 17:37

Be sure to try generating lots of different types of failed login attempts. Try from X (gdm or kdm or xdm), try from the console, try from ssh, try from sudo and try from su. Different subsystems can (and will) be configured different ways. It's not uncommon for ssh to be configured to use an internal login command that cuts around the /var/log/btmp business. Try the last command as well.

You might look in /var/log/secure to see if your failed login attempts are being stored there. But, I'm afraid I don't know the structure of the Debian log directory. Try tail -f logfile on anything in the /var/log directory. It's quite likely that ssh is logging something someplace.

share|improve this answer

Your Answer


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