
A Practical Guide To Securing OpenSSH - iuguy
http://www.minklinks.com/weblog/2010/11/19/practical-guide-securing-openssh/
======
LordLandon
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)

~~~
iuguy
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.

------
patio11
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).

~~~
iuguy
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.

------
hkarthik
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.

~~~
iuguy
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.

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

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

~~~
iuguy
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.

------
iuguy
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.

