Hardening SSH | Hacker News Reader

Hardening SSH

tech.marksblogg.com

14 pointstodsacerdoti16 comments

This isn't even demonstrating "hardening ssh" really, though. It is replacing it. It ends with using "zli" to access the remote host. I'm assuming "zli" isn't a full ssh replacement...does it work with rsync, ssh-agent, various types of forwarding?

Edit: I can see this product having merit. Just taking issue with the title...this isn't hardening ssh. It is replacing it with a product that does only the remote login part of ssh.

To me it reads a little bit too much like an advertisement for the service it uses to middle-man-secure access to SSH.

It mentions logging into the third party service with a Google account. This is adding some level of dependence-chain risk. Risks 6 and 7 in the article sound like they could be describing the risk added here.

I'm pooh-poohing too much though, it's another alternative method of securing access that might suit where other methods do not. Good to know.

The same can be done with sssd. Plus you also have sudo, pam,groups and more tied with it.

Coming here looking for genuine advice on hardening ssh (over the normal use a high numbered port, trim authorized_keys, etc), what then is some genuine advice? Does ssh actually need hardening? In what ways has it been defeated?

Start by just using ssh keys and disabling password auth.

If you wanna go further, use something like Tailscale/WireGuard to move you SSH daemon off the public internet. Or use something like Teleport or Vault to issue short-lived per host keys backed by your centralized auth source. Or do both of the above.

I understand how they all provide (good) value for MANAGING ssh keys, but respectfully, I don't understand how/that they harden ssh at all? Why does SSH need hardening? I get that if a user is mis-managing keys that is a problem, but it is not necessarily an ssh problem.

Hardening SSH doesn’t generally mean “making the openssh process more secure”. It means “making connecting to your servers more secure”. So turning off password auth, or restricting network access to the SSH daemon, or using stronger centralized auth all do that.

Most of the risks that affect SSH are around credential lifecycles, weak credentials, and credential compromise.

It still baffles me that folks would install a third party solution when OpenSSH has supported certificates - both for the client and server - for a while.

This is not a particularly thorough article overall and is made worse by the overly ambitious title. It basically starts with "ssh has problems" and moves immediately to "use an arbitrary separate tool" to solve them. But it doesn't really go into depth on or contrast against any alternatives such as built-in facilities like SSH certificates or various third party options like Amazon SSM, Teleport, Tailscale SSH, "normal" bastion hosts, etc.

Truly "Hardening" SSH involves a more robust set of options and bigger toolbox than this article suggests. In particular the bar is very high for new tools in the ecosystem and BastionZero.

I urge readers to know how high the bar should be for deploying solutions to SSH and system access ecosystem and to be skeptical of anything they read as magic solutions or that lacks an established pedigree. If nothing else, a good first step is searching HN for proposed solutions to see if this community has discussed it.

For the specific case of AWS EC2, there's also AWS session manager. It even works with Windows machines.

For ssh for the console, there's [0] aws session manager plugins. This is integrated with the authentication provider used for the AWS account. Although in the case of AWS SSO, it's not perfect: the initial sign in is manual. This is useful for connecting other tools to the EC2 instance, such as an IDE.

[0] https://docs.aws.amazon.com/systems-manager/latest/userguide...

Also see Tailscale SSH:

https://tailscale.com/tailscale-ssh/

I like how this guy always mentions the lines of code of the tools he uses, especially for areas where security is critical.

On gcloud Identity Aware Proxy is a built in similar service.

What does he mean by ssh keys being "radioactive"?

It's his summary of the numbered issues above that statement. Some of which do resonate with me. Though I don't agree that replacing client-side ssh with some propriety tool (zli) is the solution.

Yea. This reads like sponsored content to me. The claimed downsides of keys are never expanded on beyond the surface layer, nor is there any mention that there are many workflows to remediate / sidestep those downsides. Just a pitch that we can solve all our problems with this one easy SaaS payment.

Reply on news.ycombinator.com