Slashdot Mirror
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.
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.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
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.
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.
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.