Comments on SSH: Best Practices

SSH: Best Practices Are you using SSH in the best way possible? Have you configured it to be as limited and secure as possible? The goal of this document is to kick in the new year with some best practices for SSH: why you should use them, how to set them up, and how to verify that they are in place. All of the examples below assume that you are using EnGarde Secure Linux but any modern Linux distribution will do just fine since, as far as I know, everybody ships OpenSSH.

5 Comment(s)

Add comment

Please register in our forum first to comment.

Comments

By:
Reply  

+ you're using some funny port (as in used by rootkits) to run SSH service on; it's ok as a joke but not as recommendation for others (IMHO)

+ you're missing (or forgetting about) the denyhosts package, which will lock out of SSH anyone who retried his/her password after a certain number of trials and denyhosts comes with a directory of "known" or reported IPs used to bruteforce they way into SSH servers worldwide

 + denyhosts + /etc/hosts.allow is a good thing in order not to lock yourself out ;-)

By:
Reply  

Don't use port 31337 as stated in the tutorial. It was just an example. Use your own port number. If everyone starts using 31337 then the point of changing ports is no longer valid. A list of well known ports can be found

By:
Reply  

If you sometimes have to ssh in from computers that are outside of your control and therefore don't have access to your private key you can use S/Key authentication. S/Key is a one time password system that uses a program on your PDA to generate the passwords. That way if someone sniffs or key logs your password it will not work twice.

Also, if you get tired of typing ssh -p 31337 you can add that to your user level configuration file like this:
~/.ssh/config: 

Host hostname
  Port 31337
  User username

By:
Reply  

Here are some ssh-agent tricks; how to use the agent. I use these tricks daily and they help me great.

 

By:
Reply  

SSH is a great, secure tool and these suggestions are great. I would add that if you need to be PCI compliant or face some other audit requirements, you might need something more than public-key authentication.  With SSH public-key authentication:

There is no way to control which users have public key authorization
There is no way to enforce passphrase complexity (or even be sure that one is being used)
There is no way to expire a public key

as I discussed here:https://www.howtoforge.com/secure_ssh_with_wikid_two_factor_authentication

nick