6 ms·
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
by russell_h 10y ago
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 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-season-4-episode-3 http://www.slideshare.net/aspyker/netflix-open-source-meetup...
Facebook has their own certificate scheme: https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/ 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/ https://www.scaleft.com/
We're hiring if anyone is interested, my email is in my profile.
- 4ad 10y ago> 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.
- Pyxl101 10y ago> 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-secure-access-with-ssh/ https://code.facebook.com/posts/365787980419535/scalable-and... What's the best straightforward way to set up LDAP, Kerberos, etc from scratch?
- jlgaddis 10y agoYou might look into FreeIPA [0]. [0]: https://www.freeipa.org/page/Main_Page https://www.freeipa.org/page/Main_Page
- etcet 10y agoI recommend FreeIPA. You can find thorough documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/introduction.html 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.
- emmelaich 10y agoThere 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_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Services.html 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.
- tcoppi 10y agoThe 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.
- russell_h 10y agoOpenSSH 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-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu 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.
- flamedoge 10y agowhat about PKI + password auth? user auth should be encrypted using server's public key
- russell_h 10y agoIf 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.