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

[DarkOx]

Set up a VPN, Limit the list of allowed IPs

If all you want is to allow SSH there is no good reason to do this, and if you want alot more than SSH there is still probably no good reason to do this.

SSH is probably the most mature, robust VPN solutions out there with probably the among the best over all security records to boot. SSH can do port forwarding but it can also do point-to-point tunnels. Certainly if you only want to access a single host SSH should be your VPN, and even if you want to access multiple hosts across the tunnel, SSH + some shell scripts to setup routing is probably among your best options.

Should you use netfilter or pfsense to limit source ips that can connect, sure why not can't hurt; but I trust sshd with a listing port that gets Internet traffic way more than I trust BobsOMGPoniesVPNd to do it.

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.

Re:new goals

[quintus_horatius]

The goal shouldn't be to prevent your files from being seen by the NSA -- it should be to prevent your files from being seen by ANYONE

Yes, but the NSA is the gold standard of privacy protection, since the NSA is attempting to read every secret and is reportedly very good at it.

RC4, how weak is it?

[hankwang]

TFA: "... RC4 are broken. Again, no need to wait for them to become even weaker, disable them now."

Is that really so? I think RC4/arcfour is only known to leak secret data in the first 2 KB of the cipher stream, and for that reason SSH will simply feed it 2 KB or so of garbage data before encrypting the actual payliad. Or am I mistaken?

RC4 has a big advantage: it is by far the fastest cipher, which is relevant if you want to do large file transfers over slowish hardware (home-grade NAS, Raspberry Pi, old Atom CPU, etc.).

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.