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

[Pope Hagbard]

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

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

[Anonymous Coward]

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.

On the other hand, that's exactly what NSA would like you to think. I understand that I sound a bit whiny, but NSA has done so much unwarranted snooping and other crazy things that it's good to take these things seriously at this point.

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

[CastrTroy]

Point number 1 is the most important. There's very little reason to enable SSH from the general internet. Set up a VPN, Limit the list of allowed IPs, do something to limit who can connect to your server.

Re:Well Then

[Anonymous Coward]

For #2, I know at least fail2ban had a security exploit. so far sshguard has not. I would be cautious about installing these as sometimes the defense itself can introduce new security problems!

I definitely agree with #3: 2 factor authentication.

And 4 is obvious. Even in a non-internet facing install, I disable root. I don't trust local users any more than remote ones!

Re:Well Then

[GameboyRMH]

I was expecting an ITworld article teaching Babby's First SSH Server Configuration.

Re:Well Then

[Anonymous Coward]

I'm sure the editors will correct their mistake quickly.

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

[sootman]

These ten tips for securing SSH will blow your mind!

[ad]

[ad]

[start slideshow]

[you might also be interested in...]

[ad]

[things from around the web]

[ad]

[ad]

Re:Well Then

[jones_supa]

Also a big pop-up card that appears in front of the page while you are deeply focused reading it. There is an "X" symbol in the top right corner of it to close it.

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

[TheCarp]

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

The thing is to a tor service, a "port" is just an identifier that allows multiple services to have the same name. There is no underlying "address" that you can use to further attack the host. It is a lot like being behind a very restrictive firewall where you have only 1 port exposed.

It also means you can't be found in random sweeps. In order to connect to a tor service, you need its name to look it up and connect to it with, you can't just scan random addresses/names looking for ssh servers.

Some people think they are clever moving ssh to another port, but port scanners have already found them on ports like 2222 (someone thought that was clever I guess).

Re:Well Then

[Anonymous Coward]

Since the evidence points rather strongly to the NSA doing dragnet surveillance of absolutely everyone, that isn't quite true. While the chance of the NSA putting in the effort to gain physical access to your systems is practically zero, the NSA is almost certainly trying to read your communications because they are just automatically trying to read everyone's communications. The idea of recommendations like those in the article is to force the NSA to actually put some real effort in for each target of their surveillance. You can't protect yourself from state actors, but you can make sure they're only reading your communications if they actually have a reason to put effort into targeting you.

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

[Anonymous Coward]

Good thing that libwrap support is gone now from sshd.

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.

Re:Well Then

[TechyImmigrant]

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

Yes. They are good recommendations.

For example, Curve 25519 is structured such that all the usual implementation problems can't happen. See safecurves for why.

 

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

[Anonymous Coward]

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.

Has anyone made a server to handle fail2bans across a network? Like if two or more machines ban an IP within an X minute span, the IP gets banned on all machines in the network for Y minutes? And no, I don't want to use denyhosts for this.

Re:Well Then

[Anonymous Coward]

Sounds like you're smoking some serious crack. OpenBSD is as secure as vanilla centos. That is hilarious. Please do elaborate on that one because it's utter nonsense.

(as a non-technical quick start just compare number of centos patches vs openbsd patches over the past year).

Re:Well Then

[bluefoxlucid]

He doesn't use AES-CBC or Blowfish-CBC.

Re:Well Then

[Anonymous Coward]

0. Disable password login and only use ssh keys.

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

[sjames]

You don't have to be 'on the radar' anymore. The NSA has gone full on STASI lately. They're intercepting every single thing they can and keeping it indefinitely.

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?

Even if that doesn't happen, there are documented cases of employees abusing that database for personal reasons.

Re:Well Then

[Anonymous Coward]

If you're on the radar...

Linux Lands on NSA Watch List

EVERYONE is on the radar these days. But they can only cost-effectively get to a subset of "everyone".

Re:Well Then

[sjames]

4a. Even if root does need access, make it without-password.

Re:Well Then

[Shakrai]

That's pure genius right there. I'm going to share that with some people. :)

Re:Well Then

[Anonymous Coward]

The problem isn't that some people are "on the radar of any intelligence agency", it's that many intelligence agencies are wholescale scooping up the data on everybody and storing it indefinitely.

You may not be on their radar now, but if someday somebody enters "Buttle" instead of "Tuttle" in a search field (or "Shakrai" instead of "Chakrai"), or some data mining program comes up with a suspicious link between words in two messages you created maybe months apart, or you just happened to be in the wrong place at the wrong time or some some face-recognition program thinks you look like somebody else, then all of that data is going to be gone through with a fine-toothed comb by people (and algorithms) looking to prove that you're guilty of something.

Re:Well Then

[johanw]

Legimate? Not really. I quote:

1. 3des-cbc ...
Security of the cipher algorithm: This eliminates 1 and 10-12 - both DES and RC4 are broken.

I have absolutely no trust in the cryptographic opinion of someone who clearly doesn't know the difference between DES and 3DES.

Re:Well Then

[johanw]

But it is 3DES-CBC not DES-CBC. He seems unaware of the difference between DES and 3DES.

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

[goarilla]

I think he's only talking about the exploit mitigation technologies in OpenBSD (NX, ASLR, Stack protection, ...).
Not the overall level of OpenBSD's security which profits a lot from its secure programming processes.

Re:Well Then

[Anonymous Coward]

He doesn't use CBC mode because CTR and GCM modes are considered stronger and defends better against certain attacks. It's as simple as that. While there are no known attacks on AES-CBC in SSH, it's an old mode and cryptography has advanced since then. He doesn't like GCM because ssh (because of an implementation constraint) cannot encrypt the message length in the packets, which leaks information.

Re:Well Then

[Anonymous Coward]

3DES is, while not broken, weaker (and slower) than the modern ciphers. There's no reason to use it (except backwards compatibility, but if your ssh daemon mandates 3des-cbc it's _very_ old and you need to update anyway).

Re:Well Then

[Anonymous Coward]

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.

VPN is one way to do this. And far better than using a 3rd-party VPN such as Tor.

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.

Port knocking is a way to improve upon this - only open port 22 up in the firewall when another port receives a (magic?) packet from your IP first. And only open it to you.

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

At the very least require SSH keys for root. That prevents any brute force attack, no matter how secure your root password is

Re:Well Then

[jhol13]

5: Use AllowUsers. Quite often there are only one or two users who need ssh access (from external IP's), so enable only those and limit the rest to local net (or disable altogether).
6: Use non-standard port. Won't help against NSA, but helps against script kiddies (who are not targeting you).

Re:Well Then

[sjames]

You need to read the news more often. They are ROUTINELY intercepting traffic from everyone everywhere. They even got the FISA court to sign off on it.

That sounds about like the scale of STASI to me.

Note that I didn't claim they actually analyse all of it, just that they capture it.

Ask that guy in Germany that the CIA tortured for months how much of a consolation it is that it was a case of mistaken identity.

Re: Well Then

[Anonymous Coward]

Regarding port knocking, how about Single Packet Authorization with fwknop? https://www.cipherdyne.org/fwknop/

Re:Well Then

[Anonymous Coward]

The question is very simple: Do you support dragnet surveillance, yes or no?
If the answer is no, you should apply a bit of paranoia because every additional layer of surveillance makes it harder to the NSA to monitor _everyone_, plus it helps making people a target just because they happen to use effective crypto.

Re:Well Then

[Anonymous Coward]

Maybe (who knows) true for Mossad, but it seems clear the NSA is different.
The NSA is obviously a-priory after everyone. If they can decrypt or hack your accounts without repercussions and effort they seem to do it. At least if you are not a US citizen, but probably even if you are.
It's no longer "pick a target and attack them with all you have" but rather "attack everyone with automated attacks and minimal effort and see what you get".
That completely alters the situation and means that being attacked by a script kiddie and by the NSA has quite similar probabilities and the defenses are similar just a level more paranoia required.
Now you might argue that being attacked by the NSA is not a big deal, but on the other had it might mean your computer ends up being used to do attacks on whoever, which might get you in quite some trouble even if you're not afraid of the NSA itself.

Re:Well Then

[Anonymous Coward]

SSH port forwardings are unusable in congested networks.
VNC, RDP, even plain shell can easily end up with latencies in the minutes area if you tunnel them through SSH.
A proper VPN can forward UDP, which resolves the issue at least for RDP and for shell if you use e.g. mosh.
If you know a way to make a robust ssh tunnel that doesn't become unusable as soon as you try to send through more than the connection supports I'd like to hear it.

Re:Well Then

[Anonymous Coward]

CBC is considered risky since in combination with hmac there were a lot of padding-oracle style attacks.
Also if the HMAC was broken, CBC trivially allows modifying the plain-text (i.e. if you know bit 64 of the message is critical, just flip bit 0 and you know you sucessfully flipped bit 64 in the plaintext).
He also mentions that CTR+ETM is "proven secure", a property none of the other combinations have.

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

[chihowa]

For #2, I know at least fail2ban had a security exploit. so far sshguard has not. I would be cautious about installing these as sometimes the defense itself can introduce new security problems!

Most of the fail2ban exploits have been DoS, and the one that wasn't required a nonstandard installation.

Nevertheless, that is a really good piece of advice. "Keep it simple, stupid" is (or should be) the core mantra of the security field. Reacting to events (banning IPs trying to brute force passwords) is almost never as good of a solution as not needing to react to events (not (only) accepting passwords in the first place).

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

[Anonymous Coward]

I would say OpenVPN is just as mature as SSH

Re:Well Then

[epine]

A funny screed, but in the end just as wrong as what it debunks.

The Mossad does not have a bottomless budget. As a result, they generally fabricate pieces of uranium shaped like cellphones in hundred lots. They have even more expensive intrusions, which they fabricate in lots of ten, and then they have the most expensive intrusion of all, which is fabricated like a James Bond concept car (not the car that Bond actually gets, but the one he might get ten years from now).

It really does matter to edit your SSH configuration file to bump yourself up from 10^-9 cost bracket to the 10^-6 cost bracket.

Mossad is not magically except from the 80-20 law. They still try to use the cheapest effective method, and hope to haul in 80% of the catch for 20% of the effort.

If you're in the 99.999th percentile of pure evilness (backed by a private island gold reserve), it's no longer about casting a wide net, and moreover, you already know for certain that you're facing a Mossad-level adversary and you can proceed directly to paranoid schizophrenia.

If you're only in the 20th percentile of pure evilness (you fib on your tax return and download porn off some Shmoe's open wifi) it might just be true that Mossad-level adversaries filter feed at the cost-effective 10^-9 screening bracket.

They went to all this trouble to subvert NIST not because they couldn't break things otherwise, but because they couldn't afford to break things otherwise at the largest possible scale.

Re:Well Then

[jabuzz]

You want to disable passwords and use SSH keys when your worry is the NSA? Are you retarded? You will have to store your SSH keys somewhere and that immediately becomes a target for the NSA or other security agency. I have tried the SSH keys thing and it sucks from a usability point of view, and you end up with copies of your keys all over the place.

On the other hand I have a sufficiently long random (and I mean random) password that exists only in my head. If NSA or for me GCHQ want access they are going to have to break into my house, without me knowing about it. Now I guess that is possible but actually quite tough, but should I wish it would be quite easy to make that much much harder. However I don't see the point, because if they really wanted it they could just get a court order.

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

[thegarbz]

Some of us use SSH as our VPN!

Re:Well Then

[AHuxley]

Re AC and the "You can't protect yourself from state actors, but you can make sure they're only reading your communications if they actually have a reason to put effort into targeting you."
Under "collect it all" every message is in play over decades. The option exists to go back to a one time pad or number station. Air gap the networked computer and just send out your message on a VPN or Tor.
Expect every hop on any network to be tame, junk and in full collaboration with state actors. The NSA can track that message back under all networking conditions and have your ISP account logged. A sneak and peak search linked to that ISP account could update all networked devices found with extra software.
The idea is to get access to that plain text as entered before it is encrypted. The expectation is that same computer on site will be used.
If you can encrypt without using a computer and then just send the message? Nothing is found other that the encrypted message as sent.
Use any network as a number station. Number stations and one time pads work well. Just dont enter the plain text message into any device or reuse.
The next sneak and peak event would try and add cameras to capture one time pad use at a desk. Learn to cover your work :)
State actors can always work out who is communicating but what is been said can still be one time pad secure.

Re:Well Then

[sjames]

Technology has changed. The NSA doesn't have 1 in 10 people informing because it's no longer necessary and they don't have the budget for it. Instead, they just intercept all electronic communication (or at least every bit they can get their hands on). They have ceased focusing on intercepting just people of interest, now they want to grab it all. Google and MS have noticed, that's why they're starting to encrypt everything.

The rest is a matter of policy. We don't have a law against talking about the NSA so we can talk about it. I didn't say it was like the East German government, I said it's like the STASI.

I have seen more than one comment here and elsewhere from people formerly behind the iron curtain who see a disturbing similarity.

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.

Re:Well Then

[Anonymous Coward]

I Tried Securing My SSH, No One Could Ever Have Expected What Happened Next...

Re:Well Then

[johncandale]

100% true. Stopping the NSA, I.E. the government, piece meal is impossible. Once they have covert ISP level access, which they do, they have everything. This is like trying to stop a swat raid by adding a iron door to your house. Still not going to stop the battering ram which the courts will say was a ok.

Re:Well Then

[Anonymous Coward]

> "The lion's share of the population is fat and unimportant".

Obviously NSA doesn't think so.

Re:Well Then

[KiloByte]

Moving services like ssh to a higher, non-default port is not done for "security".

It won't protect you from in-depth attacks, but will save you from in-breadth ones.

Using a high port can protect even from non-thorough targetted attacks: nmap's default for example is to scan a selection of 1000 ports rather than full 64K.

Re:Well Then

[Anonymous Coward]

Can you predict the future and know that you won't be important enough in the future?

The whole point of the mass surveillance is to capture as much information as possible about everybody. This information can be used against anyone at later date if necessary.

For example, where will you be in 10 or 20 years? Perhaps you will be a political activist or top manager of a large company. Suddenly you aren't under the radar anymore, and your dirty secrets from the past would be extremely useful for your opponents.

Re:Well Then

[Anonymous Coward]

Read the article, it also gives you an option to use Tor in addition to the normal Internet to access your SSH server. If your server is really critical, then you don't enable access only through Tor.

It's not difficult to think about scenarios where SSH over Tor is useful. Suppose you are an executive on a business trip in foreign country and are using the hotel's Internet connection to access your personal SSH server. The local intelligence agency (wherever it's NSA or something else) would be very interested in knowing the IP address of your personal SSH server. Even if it couldn't attack it immediately, this information could be used in the future to attack your server in various ways (for example using a DDoS attack).

Re:Well Then

[Anonymous Coward]

This. I was already skeptical of the recommendations, then I saw "Google Authentication."

wat

Re:Well Then

[Shakrai]

Technology has changed. The NSA doesn't have 1 in 10 people informing because it's no longer necessary and they don't have the budget for it. Instead, they just intercept all electronic communication (or at least every bit they can get their hands on). They have ceased focusing on intercepting just people of interest, now they want to grab it all.

It's called traffic analysis. Frankly I don't have a problem with what they're doing, but saying so around here is political suicide. Bad actors use modern telecommunications systems; traffic analysis is one of the tools we have in the box to deal with them. Historically the Western Countries (the US/UK in particular) are very good at signals intelligence. It has a history of saving lives and shortening conflicts. In any case, nobody knowledgeable has ever truly expected privacy when it comes to communications sent in the clear.

I'll leave you with this: People of good conscience can disagree on the merits or need for what NSA is doing. I respect your opinion on the matter but not the hyperbole that you've attached to it or the FUD that others (not you, FWIW) are spreading on the subject. NSA is not that interested in you or me and they're certainly not STASI. Statements like that we can do without.

Re:Well Then

[bluefoxlucid]

Obviously the Mossad isn't that interested in you, or they'd use one of their unknown exploits to infect your PC via ad network. Maybe they'd impersonate a CA.

Re:Well Then

[sjames]

I would agree IFF they didn't retain all of the communications well beyond the need for traffic analysis AND if they stuck to their mission of protecting us from foreign threats. That would mean discarding data the instant they see that the communication was between 2 citizens unless and until they obtained a specific warrant based on probable cause based on the belief that at least one of the parties was collaborating with terrorists.

Re:Well Then

[allo]

always the same old "but i do not have something to hide / i am not interesting" argument. This is just an excuse for "i am too lazy to protect me". You do not need to be interesting to the NSA. Nobody would have something against agencies hunting terrorists. But the NSA collects everything. everything. THIS is the problem. And they collect your data, too.

Re:Well Then

[Anonymous Coward]

There's very little reason to enable SSH from the general internet.

You can collect the most recent password lists if you allow the general internet to try logging into your server.

Re:Well Then

[Anonymous Coward]

Yeah, except for the fact that we're sitting here openly talking about it.

Except you don't know what you're talking about. Just look at how the Sedition acts were used in the past when TPTB were seriously challenged at home. All it takes is for the population to reach a certain level of difficulty putting food on the table, and the elites will find any number of excuses to "restore order" to keep their own asses in the driver's seat.

Nowadays, anything that insults the dominant consumerist worldview is a candidate for active supression: Food producers are banned from labeling their products as GMO-free, government whistleblowers are criminalized at an alarming rate, Ag-gag laws now criminalize agricultural whistleblowers. And it didn't take long for the feds to start considering the possibility of labeling Occupy as "terrorist".

Then there is the War On Drugs which turned into a class and race war and helped push 1/5 of the adult population through a prison system that delights in letting people get raped under its watch. Most of those jailed are pressured into an informant relationship with the police. What you read in 2014 about militarization of police is another outgrowth of the War On Drugs.

So, yes.. the parallels are there and the comparisons are appropriate even if the ideology and history and the accents and the pretexts aren't the same.

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.

Re: new goals

[Anonymous Coward]

As long as people secure their servers. Hey, in the end the NSA bulk collection was good after all, as it made people strengthen security of ssh. And finally we can convince everybody ed snowden was a hero, as otherwise no one would have found out. Its hard to argue snowden is weakening national security when because of him people all overamerica secure their systems.

Re:new goals

[Anonymous Coward]

If the NSA can't see them, no one can. The two scenarios in this case are completely interchangeable. Copy and paste the article and %s/the NSA/anyone/g if it makes you feel better.

Re:new goals

[jdavidb]

If you're hiding data from the NSA that sounds like you're some kind of criminal terrorist who hates the US

We need to change that perception. Being concerned about privacy from the NSA means that somebody is a good citizen who is concerned about freedom.

Re:new goals

[by (1706743)]

I think we should just do the opposite of everything in the article, and then start scp'ing that He-Man video back and forth.

Re:new goals

[JohnFen]

it _is_ an american organization, built, operated and paid for by americans.

Why is this an important thing to point out? Everyone knows it, and it is totally irrelevant to the discussion of whether or not the NSA is behaving properly.

Not only so, it also operates to futher american governmental policies, and protects american citizens,

Also irrelevant to the underlying issue. You seem to be trying to argue that the NSA is actually a good organization that acts responsibly and appropriately. I disagree. Whatever good it does (and yes, it does some good) is overshadowed by the bad.

Personally, I partially agree with TheGratefulNet. Trying to obstruct NSA surveillance is a good thing -- even a patriotic thing. My agreement is partial, though, because the best thing to do is try to protect yourself from all attackers, not just the NSA. Fortunately, what you have to do to accomplish that is the same regardless of who the attacker is.

Re:new goals

[tburkhol]

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.

That is the goal. Just up until a year ago, you could mostly make the assumption that you were not being targeted by the NSA. Because the NSA has rather vastly more resources available that anyone else, securing yourself against the NSA used to be an extra level of expense that might be omitted with little extra risk. "Everyone" was really "everyone smaller than the NSA or other state actor." Now that we know the NSA is actually snooping each of us all the time, it's appropriate to use them as the limiting example of "everyone."

Re:new goals

[Anonymous Coward]

You could just do like Hasan Elahi, and just tell everyone all of your secrets.

http://www.ted.com/talks/hasan_elahi

Re:new goals

[meta-monkey]

Demanding privacy is now illegal, and you are guilty.

Re:What about

[bobbied]

Tips for shelling my secure shell?

By the sea shore no less.....

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:RC4, how weak is it?

[kriston]

RC4 isn't "broken." It is only bad when used incorrectly to store static data, like some older electronic wallet software had done. When used as a stream cipher it's very efficient and very, very secure.

Even the default re-keying interval is sufficient but if you are really skeptical you can shorten it and have it re-key based on time, quantity of data transmitted, or both.

Re:RC4, how weak is it?

[Anonymous Coward]

chacha20-poly1305 is faster than RC4.

Re:RC4, how weak is it?

[Anonymous Coward]

RC4 is broken by all cryptographic definitions of "broken". That doesn't mean anyone can trivially decrypt your RC4-protected SSH sessions, but the RC4 cipher has a large number of known attacks and is not considered cryptographically secure. There are a lot of tricks you can use to work around the attacks, but such weaknesses are a big warning sign. Attacks only get better, and uou can likely assume the NSA (and GCHQ, etc.) have even better attacks than publicly known. You should disable it.

Re: RC4, how weak is it?

[Anonymous Coward]

The assumptions made in this artic

Re:RC4, how weak is it?

[Anonymous Coward]

"but the RC4 cipher has a large number of known attacks and is not considered cryptographically secure."

There is nothing in that Wikipedia article that applies to RC4 as used in ssh, with a random key and discarding the first 1.5 KB of the cipher stream. (I did check the papers describing the March and July 2013 attacks).

It's pretty simple.

[XxtraLarGe]

Just ask Neil deGrasse Tyson!

Dropbear

[kriston]

You could save yourself a lot of time and effort and consider using Dropbear.

https://matt.ucc.asn.au/dropbe...

Re:Dropbear

[Minwee]

You could save yourself a lot of time and effort and consider using Dropbear.

You could save even more time and effort by using rlogin with a very liberal hosts.equiv file.

Or were you suggesting that every compiled version of dropbear has already implemented all of stribika's recommendations without any need for additional configuration? If so, feel free to elaborate on that claim.

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.

new goals

[Anonymous Coward]

Does that mean you use Dual_EC_DRBG?

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.

Shouldn't it be..

[Anonymous Coward]

shouldn't it be "Tips For Securing Your Shell"?

If you have to secure your secure shell then it isn't secure in the first place and shouldn't be called secure!

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

Re:Timing analysis of interactive sessions

[WaffleMonster]

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

Not that I agree with the method...

Disagree this talks only about hiding yourself using TOR.

This does not work against adversaries with access to YOUR pipe (e.g. NSA) before it hits TOR.

Re:Timing analysis of interactive sessions

[Dr. Evil]

Fair point, the article seems to be missing the key point of running a hidden service to hide yourself from traffic analysis:

You run a relay node to create cover traffic. You use the hidden service to blend in with the cover traffic.

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

Sounds good!

Re:Using audited code

[Anonymous Coward]

ok Anonymous Coward@

FTFY!

Re:Using audited code

[Anonymous Coward]

Haha, thanks.

Understanding government legality

[fyngyrz]

...most possibly not fully legal. Which is of no issue, as it is an agency of the government -- and they define what is lawful, and what is not.

The constitution defines what is permissible to the government, or not, and the government is authorized to create laws only within the limits of those permissions.

Warrantless search is not "lawful government activity" because search without warrant is forbidden to the government. The 4th amendment is very clear in its requirements and its intent. A warrant is required; that warrant in turn can only be issued in the face of probable cause; it must be supported by oath or affirmation; and it must specify the thing or things to be searched for and the place or places to be searched.

Search without warrant is completely out by any sane reading of the 4th amendment. Likewise, general fishing expeditions. When you have both going on at the same time, as we do with broad government surveillance of US citizens, the government malfeasance is only that much further into illegal, unauthorized territory.

The constitution is the document that defines and authorizes our government. It lays out some very explicit limits; when the government exceeds those limits, it is operating in a wholly unauthorized manner, no different in any way from any tin-pot third-world dictatorship.

sha1

[Anonymous Coward]

sha1 is broken for PKI, but a second preimage attack hasn't been even devised for md5, so, its pure tin-foil here.

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.

Re:Smartcarding your SSH connection

[Pathwalker]

I've considered moving my SSH private key into a YubiKey Neo; but the Neo only appears to support 2048 bit RSA keys.

I could use a larger key on a normal USB drive, but it would be vulnerable to interception when the drive was inserted. The YubiKey would eliminate that threat, but the limited key size causes me some concern.

Do people feel that the reduction in the attack surface by keeping the key secured on a dedicated hardware device outweighs the reduction in key size?

Re:Smartcarding your SSH connection

[Average]

Value judgement time, but for my money, nobody's out there brute-forcing RSA keys even at 1024-bit except, maybe, the NSA. If you weigh "everyone but the NSA" security as a bigger day-to-day concern, side-channel issues (keylogging, shared memory, copied private key files, implementation flaws, etc) are a lot more pressing realities than the almost-theoretical added security of 4kb+ RSA keys or going ECC.

Re:if you're X-Forwarding, not credit cards. For n

[bluefoxlucid]

You obviously don't understand the RC4 break. It's based on reusing the same RC4 key for multiple sessions. This doesn't happen in practice: a 128- or 256-bit RC4 key is generated each time you connect to SSH; you're only vulnerable if the NONCE and IV used are related in a specific, mathematical way, and only if they have this relationship millions of times with the same key. You also have to know the sessions share the same key.

An attack on the SSL protocol using RC4 is mathematically impossible based on what we know about RC4 weaknesses.

Re:What about

[__aaclcg7560]

Ask Mario the plumber.

Simpler

[zm]

1. Disable SSH v1
2. Disable root login
3. Enable two factor authentication

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

Re:Simpler

[thogard]

My reading of their abilities is they can can deal with public keys in some cases.

Why can't openssh require both public key and a password?

Custom Protocols

[Anonymous Coward]

Time to return to the land of custom protocols, custom encryption and even custom architecture.

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

"American" is a geographical qualification

[gwolf]

...How can you qualify the NSA as "unamerican"? They do reside in America. So do I (although my country's language is not English, this is as much America as the USA).

Yes, there are a lot of foundational myths to your country. One of them is that it is the "Land of the Free". Most countries that have been born in the last 200 years or so have similar origins and claims. But, if the country stands for freedom, it should not impose a credo to its citizens.

Hence, labeling something as "unamerican" is an oxymoron. Saying it's unamerican because it goes against personal privacy... Is more akin to saying it's un-soviet because it fosters private investment and therefore deprives society of its full economic benefits.

And do note, please, I said "un-soviet", not "un-russian".

Tempest Attack

[Anonymous Coward]

If you were seriously under attack, the guys in black helicopters could recover your keystrokes with a remote emag detection (ie Tempest) attack. You would need to live inside a Faraday cage and have your wireless router in the cage with you. The wired WAN connection would be encrypted, so you CAT 6 cables would really not need to be shielded. ...but then out comes the rubber hose and scrotum electrodes.

Don't agree about gcm vs ctr

[Anonymous Coward]

I don't think the author has it quite right, both AES-GCM and all the ETM modes use a plain text packet length, and given the choice I would always prefer GCM over CTR + SHA. It is simpler, faster on new Intel hardware, and proven to be a strong MAC if the cipher is strong.

Only the djb modes actually avoid the plain text packet length, however they are new algorithms and it isn't clear just how much peer analysis they have undergone yet. I'm not sure how big a deal this is, the packet length is going to be knowable by inspecting the traffic pattern anyhow.

The strongest NIST algorithm set is, IMHO: DH2048, RSA4096, AES-GCM-256

If you move away from NIST then the DJB algorithms are probably the best.

Use telnet

[dfsmith]

The telnet protocol can be made very secure with the right software in place.* But it's only useful when you have a pre-agreed algorithm.

* Use the data stream to carry benign traffic. Encode your critical message elsewhere, e.g., the inter-packet delays, typos, a secondary (intermingled) TCP stream, TCP retries, TCP checksum, window lengths, header packing.

Re:if you're X-Forwarding, not credit cards. For n

[Anonymous Coward]

> An attack on the SSL protocol using RC4 is mathematically impossible based on what we know about RC4 weaknesses.

No, you've misunderstood the parent (and likely the magnitude of the attacks). Parent says there's no point in keeping RC4 because attacks only get better (and the NSA probably has attacks that are not publicly known), and you'll need to constantly evaluate the new attacks on RC4 every day. The known attacks are major warning signs the cipher is fundamentally insecure. It's simpler to just disable it now. You won't need RC4 anyway.

RC4 is considered cryptographically broken because it does not fulfill the required security properties. That does not mean anyone can trivially decrypt your RC4 protected SSH session, but it's only a matter of time before that's possible.

Non-standard port anyone?

[Anonymous Coward]

where is the recommendation to use a non-standard port?

March isn't the only weakness. See WEP - RC4 broke

[raymorris]

> only if they have this relationship millions of times with the same key. Y

You're referring the March 2013 revelations about RC4 as used in SSL/TLS. That's just one in a long line of issues. In 2001, we knew that RC4 had a flaw, but we didn't think it could be exploited. It was soon used to break RC4 in WEP, though slowly. In 2005 Fluhrer, Mantin and Shamir improved the attack to crack WEP RC4 in under a minute (aircrack-ptw). In 2013, even worse news for RC4. In 2016, the attacks on RC4 expand to ???. I'm not betting MY customers' security on the answer.

Re:March isn't the only weakness. See WEP - RC4 br

[bluefoxlucid]

I'm actually referring to FMS and Klein's attack. Klein's improvement to FMS cracks WEP in 58 seconds by causing it to generate something like 100k or 1M packets. I didn't know about the new developments in 2013.

Re:March isn't the only weakness. See WEP - RC4 br

[epine]

In 2016, the attacks on ??? expand to ???. I'm not betting MY customers' security on the answer.

Good luck with having any customers by the time you whittle away every protocol with a potentially expandable attack surface.

As we don't even have a formal theory of quantum computation yet, but we do know that some things can be computed by quantum methods, I don't think any current protocol is entirely exempt from worrying cracks in the plaster.

Whatever you like to tell your customers, there's just no escaping this hard business of having to make a judgement call about which cracks to worry about and which to ignore.

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?

surprise?

[evensteven6]

Well they certainly have enough computing power... and curiosity

Downmodding this to hide it ray?

[Anonymous Coward]

Downmodding, you using ac posts, + your fails listed != you win raymorris http://slashdot.org/comments.p... it shows you shoot your mouth off on things you have no clue on (especially on Windows' security measures shown there), and then trying to hide them by downmods. I don't see you prove apk wrong on a single point from a list of 16 here either http://slashdot.org/comments.p... just you downmodding by sockpuppets instead. Shouldn't have trolled apk like the weasel you are here then http://tech.slashdot.org/comme... and he wouldn't have had to busted you up with ease as always, seeing as you had to "Run, FORREST: RUN!!!" from him there and apply unjustifiable downmods to his posts that smoked you too. Poor performance Mr. wannabe expert. Very poor. Especially downmodding last time I posted this http://slashdot.org/comments.p...

raymorris = "Run, Forrest: RUN!!!"

[Anonymous Coward]

See subject & this -> http://slashdot.org/comments.p...

APK

P.S.=> Like shooting your mouth off, trolling, thinking I wouldn't SEE this from you bigmouth? Guess again -> http://tech.slashdot.org/comme...

So, prove my points on hosts wrong raymorris (you NEVER do or have once): They're in that 1st link above (that you obviously downmodded to effetely *try* to "hide them", wrong again)... apk

Exposure of VPN

[tepples]

What's the difference between getting into your SSH from the Internet and first getting into your VPN and then into your SSH? Or how would you limit who can get to the VPN itself?

Re:This is probably not the site you are looking f

[Anonymous Coward]

Same here, trying to be funny I think.

Re:This is probably not the site you are looking f

[Anonymous Coward]

It is just humor of course. It is a pun on the typical SSL warning of a web browser.

Read over SSH

[dolmen.fr]

If you are worried about SSL, you can also download the content over SSH because the content is hosted on Github. This requires a Github account (unfortunately this has to be done over SSL) where you have setup SSH access (the later can be done with my tool github-keygen, despites it does not yet implement all Stribika advices).

git clone git@github.com:stribika/stribika.github.io.git
cd stribika.github.io
less _posts/2015-01-04-secure-secure-shell.md

Anyway whatever the state of the transport encrpytion, that will never tell you if the content is legitimate.
At least reading your local copy you will make with Git will at least ensure you that will not be affected if the server copy is later altered.

Fail2ban

[Anonymous Coward]

fail2ban in a must.

Default settings is wrong 3 tries every 10 minutes per IP address. This will make brute force attacks quite difficult.

One more recommendation

[Slashdot Parent]

PasswordAuthentication no

If SSH connections are coming in from the public Internet, you shouldn't be allowing password-based authentication. Let the bad guys have fun trying to brute force your RSA key for the next 14 million years.

Use the source, not the news article

[allo]

http://stribika.github.io/2015...

that's how to secure ssh