Tips For Securing Your Secure Shell 148
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.
Well Then (Score:5, Funny)
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: (Score:1, Offtopic)
Right? Since it's posted here I'm interested, yet suspicious of whether these are really good recommendations.
Re: (Score:3)
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: (Score:2)
Comment removed (Score:5, Insightful)
Re: (Score:1)
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.
Comment removed (Score:5, Interesting)
Re: (Score:2)
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
Re: (Score:3, Interesting)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
> 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 ver
Re: (Score:3)
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: (Score:3)
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: (Score:2)
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: (Score:3)
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:/// [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: (Score:1)
Re: (Score:2)
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 S
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Re:Well Then (Score:5, Informative)
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: (Score:1)
Re:Well Then (Score:5, Insightful)
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: (Score:2)
Some of us use SSH as our VPN!
Exposure of VPN (Score:2)
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: (Score:2)
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 [cvedetails.com] 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: (Score:3)
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: (Score:1)
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: (Score:2)
4a. Even if root does need access, make it without-password.
Re: (Score:3)
4b. Then redesign your system so that root doesn't need access anymore.
Re: (Score:1)
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).
One more recommendation (Score:2)
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.
Re: (Score:2)
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 t
Re: (Score:2)
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. [cr.yp.to]
Re: (Score:2)
I was expecting an ITworld article teaching Babby's First SSH Server Configuration.
Re:Well Then (Score:4, Funny)
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: (Score:1)
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: (Score:2)
Re: (Score:2, Informative)
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 anoma
Re: (Score:3)
>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: (Score:2)
Re: (Score:2)
But it is 3DES-CBC not DES-CBC. He seems unaware of the difference between DES and 3DES.
Re: (Score:3)
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: (Score:2)
Not the overall level of OpenBSD's security which profits a lot from its secure programming processes.
Re: (Score:2)
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.
new goals (Score:3)
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: (Score:3, Informative)
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: (Score:2)
"American" is a geographical qualification (Score:2)
...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 oxymor
Re: (Score:2)
Demanding privacy is now illegal, and you are guilty.
Understanding government legality (Score:2)
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 requ
Re: (Score:2)
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 --
Re:new goals (Score:5, Insightful)
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: (Score:2)
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: (Score:1)
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 limit
RC4, how weak is it? (Score:5, Informative)
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: (Score:2)
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.
if you're X-Forwarding, not credit cards. For now (Score:3, Insightful)
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 reconfigur
Re: (Score:2)
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 ba
March isn't the only weakness. See WEP - RC4 broke (Score:1)
> 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 ??
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:1)
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 [wikipedia.org] 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.
It's pretty simple. (Score:3)
Dropbear (Score:2)
You could save yourself a lot of time and effort and consider using Dropbear.
https://matt.ucc.asn.au/dropbe... [ucc.asn.au]
Re: (Score:2)
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: (Score:3)
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.
Timing analysis of interactive sessions (Score:3)
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... [berkeley.edu]
It can be done with clocks..
http://users.ece.cmu.edu/~dawn... [cmu.edu]
Re: (Score:3)
It's discussed in the article under "Traffic analysis resistance"
Not that I agree with the method...
Re: (Score:2)
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: (Score:2)
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 (Score:5, Insightful)
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: (Score:3, Interesting)
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 Open
Smartcarding your SSH connection (Score:3)
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... [bradfordembedded.com] for a starting point.
Re: (Score:2)
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: (Score:2)
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.
Simpler (Score:2)
2. Disable root login
3. Enable two factor authentication
Re: (Score:3)
#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: (Score:2)
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?
Not a good guide for noobs. (Score:3)
There's a pretty solid (if somewhat offensive) guide for noobs on 4chan's /g/ (technology) Wiki:
https://wiki.installgentoo.com... [installgentoo.com]
Use telnet (Score:2)
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.
This is probably not the site you are looking for (Score:3)
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?
Read over SSH (Score:2)
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 [dolmen], despites it does not yet implement all Stribika advices [github.com]).
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
surprise? (Score:1)
Use the source, not the news article (Score:2)
http://stribika.github.io/2015... [github.io]
that's how to secure ssh
Re: (Score:1, Offtopic)
Tips for shelling my secure shell?
By the sea shore no less.....
Re: (Score:1)