5 ms·

OpenSSH Server Best Practices (security related)

43 points by arb99 14y ago

peterwwillis 14y ago
(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
- deleted 14y ago
  [deleted]
dillona 14y ago
You could replace all of these with "Only allow private key authentication"
- morpher 14y ago
  Many, but clearly not all. If you added "to certain users" and "from certain hosts" you'd cover more of them.
morpher 14y ago
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.
sneak 14y ago
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...
- graywh 14y ago
  I've used timeoutd to disconnect idle users.
- Florin_Andrei 14y ago
  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 14y ago
    > 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 14y ago
      I'm talking about engineering staff, like me, my co-workers, and (very likely) you.
      - sneak 14y ago
        Who would hire someone to use ssh who doesn't know enough to encrypt their disk and lock their screen on a timeout?
maximilian 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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.
ibotty 14y ago
fail2ban is pretty great. when so many (partly very obvious) advices are included. fail2ban should as well.
0x0 14y ago
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.
timwoj 14y ago
Another thing is using Google's free authentication services to add two-factor authentication. It's very simple to set up via PAM.

43 points by arb99 14y ago

(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

deleted 14y ago
[deleted]

dillona 14y ago

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

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

morpher 14y ago

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.

sneak 14y ago

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

graywh 14y ago
I've used timeoutd to disconnect idle users.
Florin_Andrei 14y ago
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 14y ago
  > 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 14y ago
    I'm talking about engineering staff, like me, my co-workers, and (very likely) you.
    - sneak 14y ago
      Who would hire someone to use ssh who doesn't know enough to encrypt their disk and lock their screen on a timeout?

maximilian 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.

ibotty 14y ago

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

0x0 14y ago

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.

timwoj 14y ago

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