I have some servers I maintain and I'm the only one who should legitimately be logging in or even attempting to over Secure Shell (SSH). It doesn't stop other users from trying their hand though.

In one 24 hour period on 27 January 2019, my server had login requests using 128 different invalid user names. Some are likely just user names commonly found on Internet exposed systems. Others are looking for specific types of devices with exposed default user names that may also have default passwords.

I use key based authentication and lock down SSH, as you should, so this activity doesn't pose a threat to my infrastructure. It's still interesting to see what people are trying. I don't believe they're wasting their time with random attempts. I believe devices with default or common user names and passwords must be exposed to the Internet.

The full list of names that had been tried is at the bottom of the post in case you want to have a look and investigate any for yourself.

To extract the invalid names from the auth.log file which keeps track of every SSH login attempt among other activity related to authentication, I looked through the log for the information I was after.

Lines for attempts to access the server over SSH using an invalid user name contained the word Invalid.

Sample line from log file showing an attempt to log in with an invalid user name

I ran the following command to find lines from 27 January that have the word Invalid in them. It then grabs just the field with the user name by cutting on spaces and returning only field 8. It then does a sort on unique values so I don't have to deal with duplicates. It output the names to the file usernames.txt

sudo grep "Jan 27" /var/log/auth.log | grep Invalid | cut -d " " -f 8 | sort -u > usernames.txt

Here are some of the user names attempted that jumped out at me or came up in Google searches.

User Name Possible Associated App
abrt RedHat/CentOS Crash Debugger
admin Default for many network devices such as Netgear
apache Apache web server
atscale AtScale Intelligence Platform
flink Apache Flink
git Git revision control system
github Git Repository
gogs Self-hosted Git service
gpadmin Pivotal Greenplum database administrator
hduser Common Hadoop database username
jira Atlassian's Jira issue and project tracking
kafka Possible Apache Kafka username
libsys Possibly related to Libsys India
majordom Majordomo mailing list manager
mapred Hadoop mapred map reduction
minecraft Minecraft game server
mythtv Myth TV server
nagios Nagios network monitoring server
oracle Oracle database
pi Raspberry Pi
postfix Postfix mail server
teamspeak TeamSpeak VoIP
tomcat Apache Tomcat
ubnt Ubiquiti UniFi
vagrant Vagrant by HashiCorp rapid deployment manager
vnc RealVNC or TightVNC remote login software
vyatta vyatta open source router software
weblogic WebLogic Online Transaction Processing
wordpress WordPress Content Management System (CMS)

If you don't have to expose your service to the Internet, then don't. You can protect it with a firewall and VPN to your network if you need access.

If you do have to expose it, take some precautions. To secure SSH in particular, create and use a non-root user account, permit only key based authentication, disable root remote access, enable your firewall, consider an app like Fail2ban, and consider changing from the default TCP port of 22 to a high port like 2223. Keep your systems up to date and check your logs frequently.

There are sites people use to feed automated tools that scour the Internet looking for vulnerable systems. Don't let yours fall prey. You'll notice many of the names below on that list and others like it.

I took a slightly deeper look at one login,  ubnt, on my personal blog if you're interested.

Here's the full list. That's a lot of attempts for one 24 hour period.