
OpenSSH Server Best Practices (security related) - arb99
http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
======
0x0
I don't agree with the people in the article comments claiming a change of
port number is worthless security-by-obscurity. It has completely eliminated
random "drive-by" login attempts on my servers, and I'm sure that can only be
a good thing - both for staying out of any database of hosts with versioned
SSH servers (or distribution names, even) (in case a 0day exploit comes out,
either for SSH or for the distro's equivalent Apache), and for reducing
exposure in case an account with an easily guessable password is accidently
configured, at the least.

Additional configuration complexity is pretty much a non-issue. One extra
"Port" line in ~/.ssh/config or the equivalent UI textfield box in putty.

------
peterwwillis
(edit: a method for this is already in the story, but this is slightly more
flexible/secure) Rate limit incoming SSH connections:

    
    
      iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate INVALID -j DROP
      iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
      iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j DROP
      iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

------
sneak
Setting ClientAliveInterval and ClientAliveCountMax does not disconnect idle
users. It's for detecting failed network connections. Your ssh client will
still reply to protocol level alive checks even if you are sitting idle at a
prompt.

What he's looking for instead is:

    
    
        echo "TMOUT=300 >> /etc/bashrc
    

You can argue that this doesn't really enhance security, though...

~~~
Florin_Andrei
It's prudent to do this as many people just leave ssh sessions hanging open
forever, and their desktops don't auto-lock the screensaver.

It's still easily thwarted if the user keeps "top" running in it, or
something.

~~~
sneak
> many people just leave ssh sessions hanging open forever, and their desktops
> don't auto-lock the screensaver

Not "many people" use ssh to begin with.

~~~
Florin_Andrei
I'm talking about engineering staff, like me, my co-workers, and (very likely)
you.

~~~
sneak
Who would hire someone to use ssh who doesn't know enough to encrypt their
disk and lock their screen on a timeout?

------
morpher
There is some good information here (e.g., the fairly comprehensive list of
methods to deter brute-force attacks in #16). However, it looks like the
majority of the options mentioned here are the default settings for current
versions of OpenSSH.

------
maximilian
Can anyone comment on why password-less ssh-keys are bad? ("#11: Never ever
use passphrase free key (passphrase key less) login.")

I usually figure that it just generates some random number based on the time +
salt and that is more secure (brute-force attack-wise) than any silly password
I could come up with myself.

~~~
dkokelley
The password is not what is used to authenticate to the ssh remote. The ssh
private key is still used, it's just locked on the client side. You unlock the
private key with the passphrase, and then use the unlocked (unencrypted) key
to authenticate to the remote.

By using a password-free key, your private key is sitting in plain text on
your local machine, which is a potential security risk.

(Apologies is your question is more nuanced than my understanding.)

~~~
maximilian
So, the private key is encrypted on the client side, which requires that the
user type their key-password in, so that the client can send the private key
in order to authenticate?

I generally use ssh keys so that I _dont_ have to type my password in 50 times
a day. Can this be done with a key-password, or does this defeat the entire
purpose of having a key-password?

~~~
wiredfool
You can add it to ssh-agent, and it will be kept open for new connections to
use.( and, even allow you to extend the keyed login to the next hop) Some
desktops will do this automatically, Some are setup to ask for the password
each time.

~~~
jiggy2011
Something I've considered doing is creating a truecrypt volume and somehow
sticking all of my pre-shared keys and stored credentials in there, for SSH
keys , wifi keys , lastpass & dropbox credentials etc.

So I can mount the volume and be logged automatically into everything then
dismount when I'm done.

It's just the pain of rounding all of the various files up.

~~~
sneak
Or just use ssh-agent, encrypt your key, and store everything per-file
encrypted in Dropbox like everyone else does.

OSX Keychain stores wifi keys encrypted on disk with a key derived from your
user account password.

The only passwords I need to remember are my for my GPG key, my ssh key,
Dropbox, and 1Password. Oh, and my user account.

~~~
jiggy2011
I'd rather not use per file encryption with dropbox because that could break
syncing in big files.

The idea would be to have everything auto-login when the drive is mounted and
nothing auto-login when it is not.

------
timwoj
Another thing is using Google's free authentication services to add two-factor
authentication. It's very simple to set up via PAM.

------
ibotty
fail2ban is pretty great. when so many (partly very obvious) advices are
included. fail2ban should as well.

------
dillona
You could replace all of these with "Only allow private key authentication"

~~~
morpher
Many, but clearly not all. If you added "to certain users" and "from certain
hosts" you'd cover more of them.

