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

Re:new goals

[TheGratefulNet]

the current NSA is an imoral, ILLEGAL, unamerican organization.

I see nothing at all wrong with actively trying to avoid them and their illegal unconstitutional spying.

demanding privacy != 'guilty of something'

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

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

[bluefoxlucid]

It's a good write-up, but he makes a number of technical and journalistic mistakes.

The first thing that stood out to me was his claiming RC4 is broken. RC4 is only broken in known, controllable situations with key reuse. SSH is immune to RC4 exploits because the RC4 key is randomly generated at each session--unlike WEP, where each packet is a brand new session and uses the same RC4 key. Even then, you need a specific mathematical relationship between the NONCE and the IV to produce a statistical anomaly detectable over about 10 million packets to expose 1 word of the key. RC4 has no theoretical weaknesses when used for SSL.

He fails to mention why CBC isn't used, although he rejects its use. ECB would be crap, and CTR is gold; an explanation of why CBC isn't viable would be nice.

The exploit mitigation in OpenBSD isn't as fantastic as some would like to believe. OpenBSD is about as secure as vanilla CentOS, and has been for a long time; they talk big, but they're just a below-average BSD flavor with less user-friendly than FreeBSD.

It's decent, but a little overbearing.