Why you should never allow ssh into your root account…

Every so often, I walk into my office at home and glance at the console for my file server (the machine on my network that has port 22 forwarded to it) and I see new messages like this:

Minorly massaged so you’re not looking at a wall of text

Sep 13 05:56:34 gogo kernel: Sep 13 05:56:34 gogo sshd[49408]: error: PAM: authentication error for root from 188.190.98.6
Sep 13 05:56:34 gogo kernel: Sep 13 05:56:34 gogo sshd[49409]: error: PAM: authentication error for root from 188.190.98.6
Sep 13 05:**:** gogo kernel: Sep 13 05:**:** gogo last message repeated 147 times
Sep 13 05:59:41 gogo kernel: Sep 13 05:59:41 gogo sshd[49611]: error: PAM: authentication error for root from 188.190.98.6

This is the big reason why you should never allow people to ssh into the root account of a machine directly accessible via the internet: people will try to break in.

I also amuse myself by adding the IP address to my firewall’s block list, but then, I’m easily amused. I know getting a new IP address is trivial, but I want people who are trying to ssh into root on my file server to have to take that trivial step.

RAM!

The two 4GB DIMMS I bought from Newegg on Tuesday for my home server just arrived (I thought about blowing the extra money to get four of them, ditch the two 2GB strips I currently have, and push my server up to its max of 16GB RAM… but I decided I didn’t need THAT much RAM yet).  I’m going to spend this weekend stuffing that, the 96GB flash drive, and the two 2TB drives I’ve had sitting around since last June into my server.

I was encountering really sucky performance when writing to the server over the network (I tried using AFPSMB and NFS; all sucked equally); after doing some reading online, I discovered that there were two possible sources of my performance problems.  First, it could be the cheap Western Digital WD20EARS drives I bought reporting that they have 512-byte to the operating system when they really have 4K sectors.  Second, it could be that ZFS/NFS performance really sucks when you don’t have a ZFS Intent Log (ZIL) on a high-speed device.  However, the older version of FreeBSD I was running at the time had an older version of ZFS, and in that version of ZFS once you added a log device to a storage pool, you couldn’t remove it–you could only replace it.  I didn’t want stick myself in a situation where I couldn’t undo what I’d done (in case it made things worse), so I needed to wait until I could get a version of ZFS later than version 19.

Fortunately, FreeBSD 9.0 contains ZFS version 28.  I’ve updated the server to FreeBSD 9.0 my ZFS pool to version 28 last month. However, I wanted to wait until I had some time before I stuffed any new hardware into my server.  This weekend is it.