3 ms·

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'

by tyingq 4y ago

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.

BLKNSLVR 4y ago
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.
- stop50 4y ago
  The same can be done with sssd. Plus you also have sudo, pam,groups and more tied with it.
stevenjgarner 4y ago
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?
- akerl_ 4y ago
  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.
  - stevenjgarner 4y ago
    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.
    - akerl_ 4y ago
      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.

by tyingq 4y ago

BLKNSLVR 4y ago

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.

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

stevenjgarner 4y ago

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?

akerl_ 4y ago
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.
- stevenjgarner 4y ago
  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.
  - akerl_ 4y ago
    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.