A leak? You call what’s going on here a leak? Last time we had leak like like this, Noah built himself a boat! — Wells (Wilford Brimley), ‘Absence of Malice’

Our copy of the new Harry Potter novel (delivered early this morning from Amazon) is presently being devoured by GoddessJ, and it doesn’t look like she’ll be done with it until late tonight. My other projects are all at a temporary standstill, so I decided it was time to make my server’s SSH system available over the Internet, as I’d mentioned an interest in doing before.

That noise… it sounded as if millions of knowledgeable sysadmin voices suddenly cried out in terror, and were suddenly silenced… 😉 Never fear; even if a Linux-using friend hadn’t already been hacked through an SSH daemon that was ill-advisedly enabled by default in one of his various distro-hops, and I hadn’t seen a recent article that mentioned SSH server attacks, and I also didn’t already know that SSH server attacks were one of the SANS Institute’s top-twenty security attack targets, my paranoia meter (which generally reads quite high anyway) pegs the needle whenever I consider punching a hole in my hardware firewall. Assuaging the paranoid within would require plenty of research.

It didn’t take long for that research to hit the jackpot.

The first thing I found was that “protocol 1” could be a vulnerability. It looks like that’s for SSH version 1; since I’ll always be accessing the SSH server from an installation of Ubuntu 7.04 or later, which has the later version of SSH installed by default, I could safely turn that off.

Next up: disabling root access. I don’t know if this is really necessary in this case, because this is a Windows machine running the Cygwin copy of sshd and I don’t think it even has a root account, but paranoia dictates that I don’t allow root access anyway. That’s easy enough.

The next one was a little sticky: insecure passwords. The passwords I pick are all secure, of course, but I wanted to support a couple other people on that server, and the SSH server attacks that were mentioned above were all aimed at brute-force guessing of insecure passwords. I found two good solutions for that: the first involved installing a script such as DenyHosts, but I wasn’t too comfortable with it — this isn’t a standard Linux installation, after all. The other involved creating SSH keys and using those instead of passwords, then disabling password logins entirely. It took a little work to set that up, but following the instructions here, I managed it in short order.

So far as I could see, SSH itself would take care of everything else. I made the following changes to the /etc/sshd_config file, after ensuring that any other Protocol, PermitRootLogin, and PasswordAuthentication lines were commented out (which they already were, here):

    Protocol 2
    PermitRootLogin no
    PasswordAuthentication no

The SSH server was ready.

The next problem was that the IP address of our office machine is a dynamic one. Fortunately, I already knew of a solution to that, though: DynamicDNS. I set up a free account with them, configured my IP address and an easily-remembered name, and told my router to keep it updated with my current IP address when it changes. Then, taking a deep breath, I punched a virtual hole in my firewall and tried to log in through SSH using the new dynamic DNS name.

Success! Completely secure SSH access from the Internet!