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:Well Then

[Anrego]

Yup.

I'm quite confused because:

- It's not a slideshow.. apparently some information is still conveyed in article form
- It's not plastered in ads
- There was no 'please wait while your page "loads" crap'.
- It's providing information that isn't blatantly incorrect, common knowledge, or irrelevant

Re:Well Then

[Shakrai]

I stopped taking you seriously at the STASI comparison, just so you know, but I'll respond anyway to this point:

All it takes to be on the radar is to (knowingly or not) communicate with someone who (also knowingly or not) communicated with someone who is either of interest or who has been confused with someone who is of interest. And of interest need not be limited to foreign nationals working with terrorists. We know they give tips to the DEA and FBI as well. Are you sure you have never talked to anyone who talked to someone who knows a drug dealer?

The only difference between NSA and a classical gumshoe detective is that the latter's activities aren't easily automated. If you're two degrees removed from a drug dealer you were always going to land on law enforcement's desk. You'll quickly leave that desk when they determine that the lead is a dead end. The Federal Government of the United States isn't going to compromise your SSH server because you called somebody who called somebody who called a terrorist. They aren't even likely to give you more than a cursory look.

Fantasy land: "Oh no! sjames called this guy who ordered a pizza from this place that once sold a pizza to a terrorist! I need his file on my desk YESTERDAY. Find out who his high school sweetheart was; I want her in here for an interview ASAP. Get me his Facebook and Slashdot credentials while you're at it. Don't forget to put this in the President's Daily Brief, this needs to go to the top STAT."

Real world: "Hmm, the computer says we got a hit. Oh, that's a pizza delivery place. Next."

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.

Re:Using audited code

[Anonymous Coward]

yeah, check out all the OpenBSD commits. At the bottom they usually say something like "ok deraadt@" or "ok tedu@". That means that another developer actually reviewed every change. If you take a look at the source logs, almost every single commit has these.

I read some study once that says that peer review is one of the most effective techniques for catching bugs but as far as I know, OpenBSD is the only unix OS that's actually doing that.

It's why I've switched all my machines (servers AND desktops) to OpenBSD these days... and that remind me time to go make another donation...