During an audit of
/var/log/auth.log on one of my public webservers, I found this:
Jan 10 03:38:11 Bucksnort sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=184.108.40.206 user=bin Jan 10 03:38:13 Bucksnort sshd: Failed password for bin from 220.127.116.11 port 50647 ssh2
At first blush, this looks like typical
ssh login spam from random hackers; however, as I looked closer I noticed something else. Most failed
/var/log/auth.log entries say
invalid user in them, like this one:
Jan 9 10:45:23 Bucksnort sshd: Failed password for invalid user sales from 18.104.22.168 port 10552 ssh2
The disquieting thing about that failed login message for
bin is that it is a valid user in
/etc/passwd that even has a login shell:
[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd bin:x:2:2:bin:/bin:/bin/sh
I thought I had covered the all the default usernames that could login remotely when I disabled
/etc/ssh/sshd_config; discovering this entry opened new possibilities in my paranoid mind. If somehow services ran under
bin, then it is remotely possible that someone could somehow insert an ssh key into the
bin user's directory from a running service on the box, so I would like to completely disable login for the
bin user, if possible.
This server is remote, and expensive to fix (i.e. I will pay for remote hands to hook up a KVM, plus KVM rental). I am trying to figure out what I might break if I change the
binto look like this:
I ran the following commands trying to figure out what
binis needed for... However, these commands came up with no files and I could find no processes owned by
bin. What does the
binuser do anyway?
$ sudo find / -group bin
$ sudo find / -user bin
Are there any other users that should get their login shells set to
/bin/false? FYI, I have already have
Am I being too paranoid?
I am running Debian, if that matters.
This question was unexpectedly popular. I'd clarify for readers after the fact that the primary concern was preventing unauthorized logins from default system users; I had previously assumed
root was the primary threat, before forming the question. Some answers address how other users could or could not get login credentials, but that's immaterial the the main focus of the question.