Receive Alerts On SSH or SFTP Logins with Papertrail

Frustration-free log management, plus a lot more

I’ve been a huge fan of Papertrail ever since I discovered it, probably about a year ago or so. I use it mostly to monitor server logs. I currently have two servers setup to send syslog messages to Papertrail.

The Papertrail Events dashboard can be a bit overwhelming at first, but the provided search is powerful and allows you to finely control which log messages you see and which you don’t.

You can even setup saved searches to fire when a specific event occurs. For example, I have a saved search that searches for the following:
Accepted publickey for tyler

When that message shows up in Papertrail, it means that I logged in, or that someone else has logged in using my SSH key. This can be quite handy, especially if you’re a one man shop like me and are usually the only person that has SSH or SFTP access to a server.

Getting a DigitalOcean VPS added to Papertrail, especially if it’s running Debian or Ubuntu, is super easy. It just requires that you modify /etc/rsyslog.conf and add a line to the end of the file that will send a copy of the system logs to Papertrail.

Papertrail can monitor application logs, too, such as Apache httpd logs and MySQL server logs, although that takes a bit more configuration to get working properly.

If nothing else, it’s just nice having system logs aggregated in one central place, where everything is easy to search through, making it easy to find exactly what you’re looking for. If you’re an admin for one server or hundreds of servers, Papertrail could turn out to be one of your favorite tools. It’s definitely one of my favorites.

I suggest you give Papertrail a try, can’t hurt, they even have a plan that’s free forever. It’s definitely a great service for monitoring server logs.


Secure SSH By Disabling Password Logins

Make bruteforce attempts almost impossible

I always disable SSH password logins when setting up a new server, allowing authentication via private key only. It’s a good way to secure SSH all-around.

Disabling password logins in Ubuntu is extremely easy.

Open /etc/ssh/sshd_config with nano or vi. You’ll want to change options for 3 different directives, ChallengeResponseAuthentication, PasswordAuthentication, and UsePAM.

Find those directives in /etc/ssh/sshd_config and set them to the following:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Save sshd_config, and reload ssh:

sudo service ssh reload

That’s it, now you won’t be able to SSH to your server and login with a password, and neither will anyone else.

Of course, you’ll want to enable private key authentication, first. If you don’t, you’ll lock yourself out of your server.

DigitalOcean has a good article on how to do this.

Do you allow SSH password logins?

View Results

Loading ... Loading ...

Let’s go a bit farther and only allow specific users to login via SSH. We can do so with by adding a line like the one below to /etc/ssh/sshd_config:

AllowUsers firstuser seconduser thirduser

This will allow only three users to login: firstuser, seconduser, or thirduser. I usually add my AllowUsers directive towards the top of sshd_config.

After modifying /etc/ssh/sshd_config, reload ssh again like so:

sudo service ssh reload

More SSH Brute Force Protection

Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers.

So, this is a follow up to the last SSH brute force post. I didn’t realize there was such a wide selection of applications for dealing with this, but there is! The two best looking options in my opinion are Fail2ban and DenyHosts.

I’ve actually started using DenyHosts on two machines now, and it’s working very well. I chose to go with DenyHosts for a very simple reason. Community stats. I love stats.

Anyway, if you’re looking for something to protect against ssh brute force attacks, go with Fail2ban or DenyHosts, they’re still being actively developed. I can’t say the same for Breakinguard, as it appears to have been abandoned about 1 year ago. And like I said, DenyHosts does it’s job extremely well, I couldn’t ask for anything more.

If you’re looking for another solution, try using cryptographic keys instead of passwords. A tutorial on configuring SSH to look for keys instead of passwords can be found here. This was suggested by commenter pwyll.

Oh, and this is the 700th post. yay!


Stopping SSH Brute Force Attacks

A few weeks ago at work, I noticed a bunch of failed login attempts to one of our Linux servers. After doing some investigation, I found that no intrusion had actually been made, which is excellent. Lines similar to this were filling my /var/log/messages log file:

Aug 20 23:31:26 elixer sshd[22526]: Failed password for invalid user alias from port 26217 ssh2

Notice they’re trying to login with the username “alias”, which doesn’t exist on that system. In fact, all the usernames attempted don’t exist, which makes me feel a little safer. Still, I don’t like seeing my boxes actively attacked. So, to stay on top of these breakin attempts, I installed Breakinguard.

Breakinguard basically watches your log file for any failed login attempts. You can set a pre-defined number of attempts that can be executed before breakinguard will block the IP.

The Package itself does a ‘tail -f’ of your syslog, and when it identifies a matching line within your logs, it logs this ‘attempt’. If more than the pre-defined number of attempts from the same IP address are received it triggers the iptables (or any other block method defined) block and also emails you notification.

I’ve never been able to get the configure script to work for me, simply because the perl module installation always fails. So, to get around that I simply installed these perl modules manually and commented out these lines in the configure script:

$PERL -MCPAN -e "install File::Tail"
$PERL -MCPAN -e "install IO::Socket"

Those two lines execute perl and try to install the File::Tail module and the IO::Socket module. After manually installing the perl modules below and commenting out the lines above in the configure script, the configure script should run and do it’s thing without error.


After the configuration script has run, you should have a couple new files, /etc/breakinguard.conf and /etc/rc.d/breakinguard. Now, the /etc/breakinguard.conf file stores the breakinguard configuration. This is where you tell breakinguard which log file to monitor and how many incorrect login attempts are defined as a breakin.

I’m not going to bother going through all the options in breakinguard.conf, simply because they’re all explained pretty well within the conf file.

The other “new file”, /etc/rc.d/breakinguard is the script used to launch breakinguard. Run “/etc/rc.d/breakinguard start” to start breakinguard.

Once breakinguard is running, it will monitor whichever log file you specified in /etc/breakinguard.conf (/var/log/messages in my case). When it sees a failed login attempt, it will be noted. Now, when an IP fails a certain number of logins, iptables will be called to block all traffic from the IP.

Below is an example email that’s generated by Breakinguard when it blocks an IP:

BreakinGuard has blocked an IP based on suspicious activity
Please review this server.

Hostname: elixer.hostname
IP Blocked:
Last log entry that caused the block:
Aug 22 06:17:05 elixer sshd[25591]: Failed password for invalid user alias from port 45340 ssh2