Tips For Securing Your Secure Shell

jones_supa writes: As you may have heard, the NSA has had some success in cracking Secure Shell (SSH) connections. To respond to these risks, a guide written by Stribika tries to help you make your shell as robust as possible. The two main concepts are to make the crypto harder and make stealing keys impossible. So prepare a cup of coffee and read the tutorial carefully to see what could be improved in your configuration. Stribika gives also some extra security tips: don't install what you don't need (as any code line can introduce a bug), use the kind of open source code that has actually been reviewed, keep your software up to date, and use exploit mitigation technologies.

Comments

Well Then

[Anrego]

Not what I was expecting at all. This is actually a legitimate technical article.

I.. have to go re-evaluate my understanding of not just the current state of slashdot but of my life in general.

Re:Well Then

[Shakrai]

yet suspicious of whether these are really good recommendations.

Some of them are good. Then there's this:

Set up Tor hidden services for your SSH servers. This has multiple advantages. It provides an additional layer of encryption and server authentication. People looking at your traffic will not know your IP, so they will be unable to scan and target other services running on the same server and client.

That seems like a huge tradeoff in usability for not much security benefit, IMHO, particularly if the box is running services that are far more likely to be probed than ssh. Nor do I much care for the notion of having to rely on Tor if I need to manage a critical system.

It's kind of silly to wrap these common sense suggestions in the cloak of NSA surveillance. If you're on the radar of any major nation-state's signals intelligence agency you've got bigger problems than SSH. Any significant intelligence agency is apt to have the resources to gain physical access to your hardware without your knowledge, which is game over in any conceivable scenario. SSH is and always was intended primarily to protect one from nosy network operators running packet sniffers.

Re:Well Then

[mlts]

Those are OK recommendations... but I'd probably add a few of my own:

1: First and foremost, limit the IP address space of what the SSH daemon can communicate with. If the bad guys can't get to the front door, they can't kick it in.

2: Install SSHGuard, Fail2Ban, or a tarpit program. This won't stop the distributed brute force attacks that do 2-3 guesses per IP block, but it is a line of defense.

3: 2FA. I use the Google Authenticator as backup to RSA keys.

4: If root doesn't need SSH access, don't allow it.

My concern is with the bad guys getting in, although cipher choice is important. However implementing SSH is just as much about access control as it is about encryption.

Re:Well Then

[Shakrai]

The average person should be more worried about their sexual partner(s) going through their SMS history than the NSA doing the same. I know it's a shock to the ego but very few of us are interesting enough to be on the radar of any intelligence agency. The lion's share of the population is fat and unimportant.

Using audited code

[Anonymous Coward]

From the article:

You want to use code that’s actually reviewed or that you can review yourself.

This is the piece we are missing from Linus' Law. Knowing that the source code can be reviewed by anyone is a good start, but it's just a theoretical possibility. We also need proof that someone has actually done an audit.