Comment by russell_h | Hacker News Reader

Comment by russell_h | Hacker News Reader

Parent Full thread

SSH is like a candy store for advanced attackers.

Password auth discloses your password to the server. Clearly this is unfortunate if you connect to the wrong server, but it also means that a compromised server can intercept the passwords of anyone logging in.

The same extends to anyone using password auth with LDAP. In practice this means that if an organization uses LDAP with passwords for SSH authentication, the ability to execute arbitrary code on one server (combined with a routine privilege escalation) implies complete access to any infrastructure accessible with the same password. Most MFA schemes simply force the attacker to act quickly to utilize an intercepted token on a higher value target. Probably this means trying to find a copy of the private key that the devops team is using to run Ansible without having to MFA to every single server.

For small scale use private keys are a simple way to combat this, but at scale they're difficult to manage, and tend to result in high value static credentials lying around on laptops.

A lot of companies are combatting this using SSH certificates. Certificates can be short-lived (as low as minutes given the right tooling), and the CA that issues them can be heavily audited and linked to an existing identity system.

Netflix has open-sourced BLESS: https://github.com/Netflix/bless

Lyft has adapted BLESS for use without a bastion, start at slide 28: http://www.slideshare.net/aspyker/netflix-open-source-meetup...

Facebook has their own certificate scheme: https://code.facebook.com/posts/365787980419535/scalable-and...

Google has something they don't talk about that seems to be along the same lines.

Quick plug:

At ScaleFT we're building a commercial solution that uses very short lived certificates: https://www.scaleft.com/

We're hiring if anyone is interested, my email is in my profile.

The difficulty of managing ssh keys can be partially mitigated by establishing a PKI and handing out certificates to everyone, then deriving an ssh key from those. OpenSSH supports using a crl, so if you have a trusted infrastructure management of that should be fairly straightforward.

OpenSSH actually has native support for using certificates (in a custom format, not X.509), so if you're building out PKI with SSH in mind it's probably worth going that route.

See: https://www.digitalocean.com/community/tutorials/how-to-crea...

Netflix's BLESS project is a neat example of how to build a simple OpenSSH PKI using AWS primitives.

> The same extends to anyone using password auth with LDAP.

So don't do that. Use kerberos auth with LDAP, and use native kerberos support in apps, don't use kerberos with pam.

> Use kerberos auth with LDAP

Do you know of a good guide for how to set this up on Linux? Or a good book that covers the topic? I've looked into this before and it's seemed to be an absolute jungle. I'd like to explore setting this up at my company but don't know where to start.

I'd be looking for something that's comparably easy to understand and employ as Facebook's recent post about SSH with certificates: https://code.facebook.com/posts/365787980419535/scalable-and...

What's the best straightforward way to set up LDAP, Kerberos, etc from scratch?

I recommend FreeIPA. You can find thorough documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

You'd need to install and configure a FreeIPA server. They make it easy to setup master-master replication which you'll likely want to do. You'd create a user, add a HOTP secret (from a Yubikey or Authenticator app), and force the use of 2FA. Then once you add a client to the domain you'll have to log in using your password and a HOTP token.

You might look into FreeIPA [0].

[0]: https://www.freeipa.org/page/Main_Page

There is no easy route to learning and using kerberos. That said, you could start with say the Redhat admin guides.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

Most of it would be applicable to any modern Linux distro.

(Speaking of someone who setup and maintained Kerberos authenticated webapps, clients and servers for the last 10 years, with Microsoft AD as the ultimate backend).

As an aside AD is fine if you have someone to maintain it, but in the past various changes in AD, Linux and Java have made for interesting times.

Yeah, that sounds like a lot of fun for a masochist. As if LDAP isn't a big enough pain in the arse to set up, Kerberos is even worse. Not to mention how much of a pain it is to integrate it in an application.

What's so hard about Kerberos? Kerberos is orders of magnitude easier to deploy and manage than LDAP. It takes literally minutes (if you have done it before and know what you are doing).

In fact it's so easy, that I recommend anyone to use Kerberos even if they don't want to manage the complexity of LDAP. If you use NFS in any meaningful capacity, you have to implement Kerberos, even if you don't have LDAP, otherwise you're implementing a security footgun. Luckily, Kerberos is easy to set up in this configuration, without LDAP.

It's true that LDAP+Kerberos is too hard to deploy and manage, but that's LDAP's fault, not Kerberos'.

What important application doesn't have Kerberos support already? If you talk about adding Kerberos support to your own applications, I have that to be pretty easy.

> So don't do that. Use kerberos auth with LDAP, and use native kerberos support in apps, don't use kerberos with pam.

Or buy into the Hashicorp ecosystem and use Vault + one-time passwords (SSH) and dynamically generated credentials (everything else like database creds).

what about PKI + password auth? user auth should be encrypted using server's public key

If I understand you correctly, that's basically how SSH already works. The problems are:

1. Most people don't bother to verify the host key of the server they are connecting to. 2. An attacker with root on the server can modify or observe sshd in order to get the plaintext password.

Reply on news.ycombinator.com