A Practical Guide To Securing OpenSSH | Hacker News Reader

A Practical Guide To Securing OpenSSH

minklinks.com

30 points_b8r010 comments

This isn't really a configuration suggestion, more of an architecture suggestion: let's say you're like me and you have 5 VPSes. You want precisely one to have SSH exposed to the public Internet. Everybody else has SSH only listen on a private IP. (Your host can probably set those up for you. Slicehost does, for example.)

e.g.

ListenAddress 1.2.3.4 #This is not really your IP address.

You can go an extra step and drop all packets to the SSH port on the public interface in IPTables, if you want. It strikes me as being overkill but, hey, whatever.

If you need to log into any server, you do so by tunneling through your gatekeeper server. That fellow gets locked down tightly. All of your other servers are firewalled tight as drums, with the exception of public-facing HTTP servers who have 80 and 443 opened (and that is it).

This is sound advice and I've seen this in quite a few small multi-server environments. The only thing I'd say is that once you get to 5 - 10 servers you might want to look at a VPN such as openVPN (http://www.openvpn.net/), at which point all your SSH services can run on their hidden networks.

This makes a bigger difference as well if you have more than a few people accessing the boxes, and for purely remote-based businesses quite a few use this type of setup to host their 'internal' network tools like an intranet, file storage, internal wiki etc.

If you have the cash and capability, I'd recommend an IPSEC VPN over OpenVPN (using something like a low-end Cisco ASA for example, but shop around - the point is to use dedicated hardware), but if you're starting out, OpenVPN is fine.

If you're going to use weird ssh-hiding tricks like alternate ports, gateways, or port-knocking, be sure to read all about what you can do with ~/.ssh/config

  Host securebox
    #if not proxying
    HostName securebox.tld
    Port 1023
    User fji00random
    #if going through a gateway
    ProxyCommand ssh gatewaybox.tld nc securebox.tld 22
    #if knocking
    ProxyCommand proxyknock %h %p 1337 1337 900

With that, you can have

  ssh securebox

rather than

  knock securebox.tld 1337 1337 900; ssh -p 1023 fji00random@securebox.tld

(and for systems without a knocker installed, you can use something like http://sprunge.us/HJHB for proxyknock, which can be cloned along with the rest of your dotfiles/scripts)

And if you're doing public key auth, read about ssh-agent, it can store your private keys in memory so that you don't have to retype your passphrase all the time, while the "physical" key is still protected if stolen. In my bash_profile, I have

  SSHAFILE=/tmp/.$(whoami)-ssha
  
  if [ -n "$SSH_AUTH_SOCK" ]; then
    echo "We has auth!"
  elif [ -f $SSHAFILE ]; then
    . $SSHAFILE
  else
    eval `ssh-agent | tee $SSHAFILE`
    chmod 600 $SSHAFILE
    ssh-add
  fi

This runs ssh-agent if it's not running, and sets proper env variables if it is.

(also, the ssh-agent can be forwarded, so you can use your private key to auth into box C, from box B, while the key is only on your local box, A - this can also be added to your .ssh/config)

This is also good advice. I didn't want to put it in as I just wanted it to be an explanation of my own position on port munging and to keep it fairly simple, but ssh-agent is a great way of making multiple ssh accesses easier.

As a total Linux n00b, I was given the advice to also run SSH on a non-standard port 4 digit port like 4232 instead of 22. I don't know how effective that is, but it sounded like good advice to me.

Running SSH on a different port sounds like good advice because the automated scanning tools tend to focus on port 22.

However, if you're vulnerable to the scanners then you haven't actually addressed the vulnerability they exploit. What you're looking at is a form of security by obscurity that reduces the number of low end attacks, but if someone port scans you, finds the SSH port and runs the same attacks you're still going to get compromised.

Another thing to consider is that if you're moving SSH ports your OS will still respond to requests to connect over SSH by telling the scanners that there's no SSH service running on that port. If you're being metered for bandwidth by bytes transferred it shouldn't be a lot (unless you're getting really hammered by it, which tends to happen when the IP address has been previously compromised).

The correct way to deal with this is to use only public key authentication (which stops people getting in through password brute forcing) and to block the port with a firewall with exceptions for the places that you access it from. You can find out where you're accessing it from by going through the SSH logs.

By all means swap ports if you want to, but don't rely on it alone.

That doesn't dispense from using the advices in this article, which is a basic description of my setup. Look at my home PC logs :

    $ sudo grep sshd /var/log/messages* | wc -l
    23084

Of course I connect several times a day, however you see the sheer number of scans, the oldest message log is less than one month old.

It is funny, but Theo (OpenSSH leader developer) thinks that SSHv1 is more secure than v2:

http://www.ossec.net/dcid/?p=10

To be fair he's not saying that. He's saying that he's concerned about the increase in complexity of the SSH2 code base. Given that was 4 years ago I'd be surprised if the SSH2 code base hasn't been thoroughly audited by the team.

I think it was a valid concern to have if SSH2 hadn't been audited at the time, given that you're trading known issues for an unknown solution that may or may not work, but to infer he thinks SSHv1 is more secure than SSHv2 in that post is slightly inaccurate.

Incidentally, if you have any top SSH tips, please do post them here so that the next time any questions about SSH come up we can refer to a HN post.

Reply on news.ycombinator.com