OpenSSH has a history of security. Only rarely are holes found in the actual program. It’s much more likely that a system will be compromised through poor configuration of the SSH daemon. Ideally, an SSH config would allow only protocol 2 connections, allow only specified users to connect (and certainly not root), disable X11 forwarding, disable password authentication (forcing ssh keys instead), and allowing connections only from specified IPs. These config options would look like this:

Protocol 2
PermitRootLogin no
AllowUsers demo
X11Forwarding no
PasswordAuthentication no

Allowing connections from only specified IP addresses would be accomplished by adding something like the following to /etc/hosts.deny:

sshd: ALL # Deny all by default
sshd: 192.168.1.0/255.255.255.0 # Allow this subnet
sshd: 4.2.2.1 # Allow this IP

(You could also accomplish this with iptables, but I think editing the above file is simpler.)

But the last two options (disabling password auth and allowing only certain IP addresses) limits mobility. I constantly login to my slice from multiple IPs, and I also need to login during travel when I may or may not have my key on me.

The main thing these two options protect against is a brute force attack. By allowing password logins from any IP, we give the attacker the ability to exploit the weakest part of SSH. This is where DenyHosts comes in.

DenyHosts is a python script which attempts to recognize and block brute force attacks. It has many attractive features and is included in the default Ubuntu repositories.

$ sudo aptitude install denyhosts

The config file is located at /etc/denyhosts.conf. It is very simply and readable. I recommend reading through it, but most of the default options are acceptable. If any changes are made, the daemon must be restarted:

$ sudo /etc/init.d/denyhosts restart

Note: Many people also advocating changing SSH’s default port to something other than 22 (more specifically, something over 1024, which won’t be scanned by default by nmap). The argument in support of this is that many automated attack scripts look for SSH only on port 22. By changing the port, you save yourself the headache of dealing with script kiddies. Opponents to changing the port would argue that the annoyance of having to specify the port number whenever using ssh or scp outweighs the minute security benefits. It’s a heated argument. I lean toward leaving SSH on the default port.

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

$ sudo aptitude install subversion

Read more…

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Three of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Four.

Last week I moved this domain’s email to Google Apps. Slicehost has a guide to creating MX records for Google Apps. I have a couple other domains with Google Apps, along with a couple domains hosted locally with addresses that simply forward to my primary, Google hosted, email. I also need to send mail from the server. To accomplish all of this, I use Postfix.

Read more…

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Two of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Three, Part Four.

Now we’ve got a properly configured, but idle, box. Let’s do something with it.

Nginx is a small, lightweight web server that’s all the rage on some small corners of the Net. Apache is extremely overkill for a small personal web server like this and, since we’re limited to 256MB of RAM on this VPS, it quickly becomes a resource hog. Lighttpd is another small, lightweight web server, but I’m a fan of Nginx. Try it out.

Read more…

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part One of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part Two, Part Three, and Part Four.

Slicehost has an excellent article repository, containing guides on a number of subjects. After building a fresh Slice, you should first follow Part 1 and Part 2 of Slicehost’s basic setup articles.

I use slightly different coloring in my bash prompt, so, rather than what Slicehost suggests in their article, I add the following to ~/.bashrc:

Read more…

Yesterday I moved this domain over to Slicehost.

Ian first told me about Slicehost when we were both looking to move away from Dreamhost last November. Initially, we both intended to find another shared host, but that proved far too difficult — it seems most hosting companies have something against shared hosting with decent limits and ssh access (that last part is the kicker).

I signed up with Slicehost at the end of last year and tinkered around with it for a month or so, experimenting with setting up the server in different ways. Eventually, I found an Ubuntu-Nginx-PHP-MySQL-Postfix-Dovecot setup that I enjoyed, and one which I was comfortable administering. In the beginning of the year, I moved a couple of my domains over to the Slice. It’s been a great experience. I’m not sure why it took me 6 months to finally move this domain — my primary one — over. Running a VPS is deceivingly simple* and well worth the effort. If you’re currently running on a shared host and have some basic competency in a UNIX environment, I’d recommend giving it a shot.

In a bit I’ll post a series of guides, compiled from my notes, on how I setup the server.

* It’s deceivingly simple if you’re not running a full mail server with virtual users running around everywhere. That part was a pain. Hence, the move to Google.