> By default KeyBox will overwrite all values in the specified authorized_keys file for a system.
This honestly seems like a terrible default. I want an explicit something when I'm about to lock myself out of my systems.
OTOH, the prerequisites are substantial enough that you're hardly likely to install it by accident. I suppose it's a better fit for brand-new hosts on both fronts. (But then, as I see it, all the hard parts around key management are around getting it reliably deployed across the entire system, which means also on old, long-running boxes. If we could all wipe our prod infra and start again from read-only media ((which we should probably do more often, to the extent that circumstances permit)) it wouldn't nearly as hard of a problem.)
I don't know, Google has a web-based shell for their cloud platform that uses oauth and deploys keys (very similar to the OP project) and it's not half bad. I do still prefer to ssh in from the command line using gcloud, but the web-based tool is acceptable.
I don't know, I use the chrome ssh shell from my chromebook and never have any issues. I set it to open as window, put it full screen, ssh somewhere and fire up tmux. No complaints.
"KeyBox layers TLS/SSL on top of SSH and acts as a bastion host for administration. Protocols are stacked (TLS/SSL + SSH) so infrastructure cannot be exposed through tunneling / port forwarding."
Okay: you connect with your browser to the server over tls and from there via ssh to the server ... where does the layering come into play?
I think what he's saying is that you can't get directly to SSH, but have to go through the TLS web control panel.
This seems to make an assumption that the security is equal to these two (web I/F w/ TLS plus SSH) combined in a chain, when in fact I think it now introduces a possibly weaker link.
And now I'm the one making an assumption that: if you can break into KeyBox, then you have full control over the OpenSSH connection too. Ultimately it comes down to which you trust more: KeyBox or OpenSSH.
(Note that this is also partly true of things that just create user accounts and sudo roles like Userify, but Userify provides a much lower degree of direct control over the remote server as opposed to a channel straight into that server. Even if you broke Userify, you'd still need to gain access to SSH, which might not even be possible from your network, and certainly all of that would show up in your logs anyway, since it's pure SSH turtles all the way down...)
If people like this, they will probably find the Apache Guacamole project interesting. I was surprised to here it is a superset of this (RDP/VNC/SSH bastion box) but also handles key auth, perhaps insecurely architecturally, even if they have passwords for the remote desktop stuff compressing it and then sending it over HTTPS using a protocol they designed back in 2006. They added SSH to boot.
I actually think web-based SSH is not a bad idea, I just wish NaSSH (the Chromium shell) was better used.
If you're interested in centralized key management that doesn't compromise private key security, I have written this for EC2: https://github.com/kislyuk/keymaker. It uses IAM to store public keys, and each instance fetches them on demand.
Who would use this and why would they use it? On all the servers I have access to, I manage one key, my own key. Why would I need a "SSH Access and Key Management" system for a single key?
Yeah... coming at this from the standpoint of a heavily invested Saltstack user, I really don't see the reason for this to exist. It removes all the other cool things SSH does besides just giving you a shell, with a much, much worse user experience.
Can you elaborate on the CA signing with OpenSSH? You have a CA verify keys with metadata and then use LDAP to verify that metadata? It sounds very interesting.
Openssh supports certificates and signing of keys, with expiry. Couple that with LDAP for account management, and you shouldn't need to manually add keys to any servers.
LDAP management on non-Windows systems is like stepping back 30 years.. last I checked, there wasn't even a supported UI for directory operations (typing DN's by hand is for the birds!)
Windows AD in all its subtle brokenness is a great deal easier to use.
> LDAP management on non-Windows systems is like stepping back 30 years.
How so? And managing which components -- the directory server or the clients?
> there wasn't even a supported UI for directory operations
What directory operations? add/mod/del? There are quite a few packages that handle that. Or are you talking about operations on the server side?
> typing DN's by hand is for the birds!
I concur. Though, it's pretty rare to type in a DN anywhere. I can't think of many places where a simple RDN or search filter on a unique value (uid, mail, etc.) doesn't suffice.
Both. Again, I may be coming from a standpoint of ignorance here, but setting up a Linux client requires manual mucking about with PAM and its associated config files, with different steps required for every major distro.
Same with the server side - there's no good equivalent to the Windows' "Active Directory Users & Computers". Plenty of good command line tools, but I don't think those are that useful when reasoning about a "tree" structure used in LDAP.
We never standardized a viable schema that covered the majority of real-world enterprise use-cases. Active Directory did. We got stuck with the broken rfc2307 (essentially NIS-in-LDAP), and the slightly better but abandoned rfc2307bis.
Without a standardized schema, every management tool out there had to either expose LDAP directly, or provide a limited subset of operations supportable across random schema.
We could solve this issue with a new RFC defining a modern standard server schema, including things like sshPublicKey, but I don't know if there's any UNIX/Linux vendor still alive that would invest in doing so.
I've never managed an LDAP server from the command line on Linux.
As for PAM, I did a PAM LDAP config once about 8 years ago, and have never needed to make a change since. Since then it's been a matter of a few config files that are part of the standard config we deploy automatically to new systems. It's not exactly particularly much effort.
We actually offer a pretty robust LDAP/AD integration on Userify, but I still recommend against it, especially since it's not just painful but adding LDAP/AD decreases overall security. I used to like LDAP in the early 00's, but now I just think it's anything but lightweight.. as well as insecure and obsolete.
Using a 3rd-party cloud-based service to manage server authentication, SSH keys, et al, seems insanely insecure however -- especially when your alternative is simply running LDAP locally.
0. I believe that both LDAP and AD have complex models (well, arguably less complex than Vines/NDS/x.500/etc if you go back that far) and they're certainly more secure than NIS/NIS+ based on historical vulns, but I find it hard to argue that they're 'secure' based on their long and sordid history of vulns ( https://www.cvedetails.com/vulnerability-list/vendor_id-439/... )
0a. and, well, I wouldn't want to connect boxes to LDAP because I prefer to log into my boxes, even when LDAP is unavailable, the VPN is down, etc. but, nscd et al.. caching doesn't work either on an autoscaled box in the cloud, nor would I want to expose my enterprise directory infrastructure to my VPC. I also don't want to introduce a new PAM and NSS configuration on every single box (with separate layering for different boxes into different projects etc) and introduce yet another avenue for mistakes and compromise... was that required, requisite, or optional? Ergo, obsolete. :) (imo)
1. (btw, We don't do server authentication. That is a key difference between a directory and Userify. We only distribute keys. The servers themselves authenticate their own users with Userify just like with the traditional model, whereas with a directory the LDAP/AD server itself performs every authentication.)
2. We also recommend purchasing and running Userify Enterprise locked down locally to your VPC/LAN, and our larger customers tend to prefer that as well (especially when connected to LDAP w/ the same disconnected model we designed into our core product). We also offer a free cloud-based edition for unlimited use because we're nice like that.
But, seriously, people who are happy with their current solution should probably stick with it. I don't expect to convince you to take another look, and I do agree that there are good arguments to be made that LDAP/AD is neither insecure nor obsolete. I just disagree with (most of) those arguments. ;)
note:
AD/LDAP connectivity in Userify: you can still authenticate natively via LDAP/AD, while Userify provides a user-friendly dashboard for key management for your teams. A particularly cool demo: remove or disable an account in Windows AD and seconds later watch all of the SSH sessions on all of the servers in all of the projects terminate. It's very slick.. and that's another thing that LDAP/AD directory authenticated solutions can't do.
> but I find it hard to argue that they're 'secure' based on their long and sordid history of vulns
The big difference here is that vs. a third party setup, my LDAP setup is running entirely behind our firewalls and not reachable from outside a suitably encrypted VPN. It's certainly possible to do stupid stuff with it.
> 0a. and, well, I wouldn't want to connect boxes to LDAP because I prefer to log into my boxes, even when LDAP is unavailable, the VPN is down, etc.
This is only an issue if you don't ensure you have at least one account that is present locally on the box that you can authenticate against.
With what I suggested - LDAP for user info, OpenSSH certificates for authentication and authorisation, any user that can be looked up locally on the box can be logged into (with the caveat that you then need to explicitly revoke keys for those users) even when LDAP is down, giving you an easy out.
But making LDAP quite resilient to outages is easy, by replicating it and specifying more than one server to connect to. For that matter, slapd is lightweight enough that you could run replicas on most servers if this is actually a problem (it's never been for me).
> nor would I want to expose my enterprise directory infrastructure to my VPC.
Why would you need to? Filtering what you replicate is easy enough.
> 1. (btw, We don't do server authentication. That is a key difference between a directory and Userify. We only distribute keys. The servers themselves authenticate their own users with Userify just like with the traditional model, whereas with a directory the LDAP/AD server itself performs every authentication.)
This is only true if you want it to be. It is not true if you use OpenSSH certificates for the authentication.
> A particularly cool demo: remove or disable an account in Windows AD and seconds later watch all of the SSH sessions on all of the servers in all of the projects terminate. It's very slick.. and that's another thing that LDAP/AD directory authenticated solutions can't do.
That's got nothing to do with LDAP, and everything to do whether a specific application supports periodically checking whether or not a user or key is still authorised, or not. LDAP is just a replicated data store.
Some applications do, some don't. For my part it's not generally an issue because their VPN key will get revoked and will immediately stop working, at which point all other connections will fail and time out whether or not individual applications pick up that the keys have been revoked and the user removed.
If you insist on doing this at the level of individual ssh connections, it's not particularly hard to force connections through a command that will periodically check that the key is still authorised.
I don't doubt that you have a slick solution, and I'm sure it'll be great for some. I don't particularly like LDAP. But for me at least, trusting this to a third party - even though it sounds like you're doing a lot of things the right way - is something I'd be extremely reluctant to, while LDAP is proven and despite various warts and problems, it's well understood and well supported by most applications we use.
0) it's enormous: both as an implemented application and as a protocol and specification. Complexity is the enemy of security.
1) it widens your network footprint and isn't hardened against modern attacks (all LDAP directories that I'm aware of also have a regrettable history a la bugtraq/cert). (even without bringing krb5 into the picture)
2) it is complex and allows schema/ACL changes to expose attributes in non-obvious ways
3) no commercially available LDAP implementation natively encrypts all data
5) A centrally managed directory represents a very rich target for the secrets it contains
6) particularly when used as an authentication backend, it also presents a nice DoS target. (I have personal experience from a previous life..) :(
7) An LDAP server exposed to a LAN is rapidly (today) approaching being exposed to the Internet as VPN connections join multiple clouds and formerly internal datacenters, for anything but the tiniest of network footprints.
Obviously many of these concerns can be somewhat mitigated but my strong personal opinion is that the size and complexity of LDAP makes it its own worst enemy. With that said, there's no real replacement for it, right?
With regards to things like SSO and SAML2, oauth (which also has its own share of problems due to the same problems of size and complexity) is beginning to make the need for an enterprise-wide directory moot, but this will obviously take time.
Not to mention - implementation to integrate with something like FreeIPA or similar is just unmitigated pain, both up front (i.e., if you want to run it somewhere like AWS without control over reverse DNS) or on each node (I've written PAM modules before and I still think making PAM changes is a big pain and not without significant risk.)
Regarding insecurity: I don't give much credence to a "history of serious problems". Any (and I do mean any) application which deals with arbitrary input and data types has had a history of particularly nasty security holes.
You'd eliminate every major web browser here too. I see a large number of CVEs as a good thing, as that means there are eyes on the code and the exploits are getting found and fixed. The alternative is worse; it means there are bugs and they aren't being found.
Survivor bias :)
Regarding complexity: Security/authentication tools are complex, and they kind of have to be given the number of requirements, ciphers, data types, etc. There is no solution to this problem.
Regarding attack targeting: Any repository used for authentication will be a DoS/hacking target. Again, it's nature of the beast, it's a high value target and always will be.
Regarding SSO/SAML/oauth: Those have to authenticate against something, yes? What is that "something" in this case that makes it a true alternative?
How does that compare with what FUDO can do? FUDO intercepts and records ssh, rdp, vnc, mysql, oracle, etc. It can allow users to login to servers without actually knowing the real credentials. You can use the web interface to "share" a session with a remote support engineer and choose when they can have control over the session, etc etc.
Why? Deploying an application with Java is very easy and you can have intense monitoring built in with out having to use a third party like NewRelic (even though NewRelic adds a lot).
Java is always a mess to debug/troubleshoot. It eats memory worse than a bloated browser, and is slooooooow. I personally avoid projects that require java if I can help it.
I'm going to have to flat out disagree with you. I hear this all the time from java devs, but have never seen it in real life. Every implementation I've personally seen of java is extremely slow, and has horrible debugging utilities.
Ok. I'm going to have to disagree since I've seen it in real life several times. Also many large distributed system projects, such as Cassandra, Elasticsearch, Hadoop, etc. are all written in Java.
I guess we'll just have to disagree due to differing experiences. How does a language being used in different distributed system projects mean it's fast? It's just the language they chose to go with. That decision could have nothing to do with speed.
Ah yes, let's judge a project based on its implementation language. Because every Java program is insecure by default, and no exploits exist for anything written in C. Sigh.
Exactly this - I don't understand this service. You lose your normal terminal, stdin/out redirection, port forwarding, (probably) special keys handling, and others. And instead you get what openldap provides. This service even integrates with your own openldap!
This honestly seems like a terrible default. I want an explicit something when I'm about to lock myself out of my systems.
OTOH, the prerequisites are substantial enough that you're hardly likely to install it by accident. I suppose it's a better fit for brand-new hosts on both fronts. (But then, as I see it, all the hard parts around key management are around getting it reliably deployed across the entire system, which means also on old, long-running boxes. If we could all wipe our prod infra and start again from read-only media ((which we should probably do more often, to the extent that circumstances permit)) it wouldn't nearly as hard of a problem.)