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

[fahrbot-bot]

Right? Since it's posted here I'm interested, yet suspicious of whether these are really good recommendations.

They are good ideas. They're just actually written by the NSA to make their lives easier...

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

[Eosi]

I agree, sounded like an NSA recipe for how to Encrypt things, so they can decrypt it easier, all at 350 degrees for 45 minutes, till light and golden brown.

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

[phantomfive]

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

If you are worried about the NSA, then Google is known to be a collaborator.

Re:Well Then

[bluefoxlucid]

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.

A Microsoft engineer published that all computer security is silly. His insight follows:

My point is that security people need to get their priorities straight. The “threat model” section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition.

In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@ virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT.

The Mossad is not intimidated by the fact that you employ https://./ If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.

In summary, https:/// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN’T REAL. When it rains, it pours.

Paragraphs added to make it not suck reading.

He suggests using strong passwords to keep your ex-gf from hacking your e-mail and publishing your Craigslist correspondence with the entire m4m section to your parents; and possibly magic amulets or changing your name and moving to a submarine to avoid the Mossad.

Re:Well Then

[TechyImmigrant]

>He fails to mention why CBC isn't used,

er. DES-CBC. It's the DES part, although CBC had a way of exposing implementors inabilities to show restraint in situations with limited entropy.

Re:Well Then

[bmimatt]

Moving services like ssh to a higher, non-default port is not done for "security". It is primarily to reduce the noise written to logs. More noise = larger logs = more CPU cycles to process. Probably never intended to be "clever".

Re:Well Then

[chihowa]

4b. Then redesign your system so that root doesn't need access anymore.

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

[MSG]

I was thinking the same thing. 3DES isn't deprecated because it's insecure, it's deprecated because it's SLOW. Its security is fine.

Re:Well Then

[WuphonsReach]

Moving services like ssh to a higher, non-default port is not done for "security". It is primarily to reduce the noise written to logs.

A reduction of 2-4 orders of magnitude. Which brings benefits to the security side because you have far less false positive reports to wade through. So it's not primarily done for security, but every little bit helps.

Re:Well Then

[Shakrai]

That sounds about like the scale of STASI to me.

Yeah, except for the fact that we're sitting here openly talking about it. Or the minor little detail that you don't have to worry about 1 in 10 (some studies say 1 in 6) of your neighbors being informers for a Government that will shoot you dead if you attempt to emigrate.

Seriously, these comparisons are about on the level of the standard issue Nazi analogy. It's pure hyperbole at best and deliberate ignorance of history at worst. It's also a tad bit offensive to people who actually grew up in the East Bloc and have a taste for what genuine oppression feels like.

Re:Well Then

[DMUTPeregrine]

It's not even about evilness.

The NSA has a summer program where academic mathematicians (professors) can go to work. Back in the late 90s, my father (a mathematician) participated. Of course, he had to get security clearance, so they know everything important about him.

He's now quite vocally against the NSA and their dragnet spying.

If they're not paying special attention to former employees, especially former employees who worked on the actual crypto math, and especially former employees who publicly voice their disagreement with the organization, well, the NSA would have to be utterly moronic.

It doesn't take evil to be a target.

new goals

[jsepeta]

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. If you're hiding data from the NSA that sounds like you're some kind of criminal terrorist who hates the US, not a run-of-the-mill responsible sysadmin.

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'

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

It's pretty simple.

[XxtraLarGe]

Just ask Neil deGrasse Tyson!

if you're X-Forwarding, not credit cards. For now

[raymorris]

If you're transferring large amounts of information, including X-Forwarding AND never access systems with very sensitive data such as credit cards, RC4 is probably okay FOR NOW. However, weak attacks tend to become complete breaks. It's entirely reasonable to expect that RC4 may well be utterly broken in a year, or two or three. If you're going to review your algorithm choices annually, you can probably keep RC4 for 2015. You'll need to check again in 2016 though. Personally, I'd rather not reconfigure all my systems' ssh very frequently, so I'd remove any algorithms that have been weakened, before they are completely broken.

Timing analysis of interactive sessions

[WaffleMonster]

The top of my list is timing analysis of entered commands. You SSH into someplace and later type a password or something worth knowing. Timing between keystrokes can be used to recover information about what you are doing.

It can be done with microphones..
http://berkeley.edu/news/media...

It can be done with clocks..
http://users.ece.cmu.edu/~dawn...

Re:Timing analysis of interactive sessions

[Dr. Evil]

It's discussed in the article under "Traffic analysis resistance"

Not that I agree with the method...

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

Re:Dropbear

[janeuner]

This comment is funny, because:
> 2013.56 - Thursday 21 March 2013
> - Added hmac-sha2-256 and hmac-sha2-512 support (off by default, use options.h)

So now, as I work to build an appropriate dropbear binary (or possibly go straight for the openssh package), I can sit here and contemplate all the time and effort that I am saving by using dropbear.

Smartcarding your SSH connection

[Average]

One bit of paranoia the author might add is moving your private key completely off of your desktop into a smartcard that does the RSA or ECDSA step and, being a far more limited microprocessor, should be more securable than processes running on a general-purpose networked computer and multitasking OS.

I believe there are ways to do ssh with PKCS-based smartcards, but the method used around here is based on PGP/GPG keys and either the "OpenPGP Smartcard" (ISO smartcard form factor, requires a smartcard reader) or the YubiKey Neo (USB pen-drive form factor). You create a key pair (possibly using the smartcard CPU itself). You use gpg-agent with OpenSSH (or PuTTY) support instead of ssh-agent/pageant. The private key never leaves the device (the little bit of flash memory in the chip) and is designed to be unrecoverable. The RSA authentication step happens in the microprocessor on the card. The card has a PIN and is designed to lock after a couple missed PINs.

http://www.bradfordembedded.co... for a starting point.

Not a good guide for noobs.

[snarfies]

There's a pretty solid (if somewhat offensive) guide for noobs on 4chan's /g/ (technology) Wiki:

https://wiki.installgentoo.com...

Re:Simpler

[WuphonsReach]

#3 should be "only allow public key based authentication"

#4 would then be "enable two factor"

(Not using passwords for SSH logins can be done out of the box with a simple config file change. Enabling two-factor is a good bit more complex.)

This is probably not the site you are looking for

[dszd0g]

Anyone else getting "This is probably not the site you are looking for" at the top of the page, and at the bottom of the page after the blog it says:

"You attempted to reach stribika.github.io, but instead you actually reached a server identifying itself as a shape shifter humanoid reptile alien. This may be caused by a misconfiguration on the server or something more serious. An attacker on your network could be trying to get you to visit a fake (and definitely harmful) version of stribika.github.io. You should not proceed."

The SSL certificate matches stribika.github.io so according to my browser I am going to the correct site. I am not sure if this is meant to be humor or if there is some sort of additional interception detection. I have no idea what it would be doing beyond the SSL checks?