[Cryptography] Applying the Mesh to do SSH really right

[Howard Chu]

Phillip Hallam-Baker wrote:
> April King started a thread on Twitter about how to use SSH in the enterprise: Why aren't people using the SSH PKI, why do people roll their own key
> provisioning scripts knowing these are almost certain to be disaster areas?

Good question. Pretty much every pain point you outline here is already solved in enterprises by LDAP.
Rolling any other solutions just sounds like pointless protocol proliferation.
> 
> At present, the Mesh is almost ready for release, I am just working on packaging up the service/host end. It passes all its unit tests (on a good day). 95% of
> the documentation is good.
> 
> The current implementation does support management of SSH keys but only in a rudimentary, proof of concept fashion. The next step is going to be to work out how
> to make the best config possible without the user having to think because any security system which requires users to be thinking about security will fail.
> 
> 
> My threat model is much broader than most people's. I am very concerned about insider threats. Sure, an enterprise can set up an SSH PKI and make use of that.
> But what if Mallet is the administrator? Just how many of these big ransomware attacks involve an insider component is one of those questions that is probably
> not asked enough.
> 
> Another irritation I have with open source security apps in general is that they all end up reducing key security to the lowest common denominator. The Windows
> platform has secure means of storing user keys. So does OSX. Linux has several. But the intersection of these schemes is storing private keys on disk
> unprotected unless the security conscious user wants to make their life miserable by adding a passphrase.
> 
> The big concern for the enterprise is SSO but I interpret that differently, I read SSO as Single Sign Off. Single Sign On is a user convenience issue. The
> enterprise security concern is deactivating the user the minute they are called into the office for their termination interview. I would like to have a realtime
> dashboard that allows a privileged user to see exactly who logged in to every machine in the system. And I can use my Mesh threshold capabilities to limit
> potential for abuse. 
> 
> I have seen people describe various OAUTH approaches. No. no. no. Even if you could understand what OAUTH is doing (and you can't), the only reason to use OAUTH
> is so you can authenticate in a Web browser. Chrome is now six and a half trillion lines of code and thus presents an attack surface the size of Alaska. In a
> few more years, Chrome will become sentient and become an insider threat in its own right. What the hell are you thinking?
> 
> Yes, some of this can be done by deactivating accounts. But that doesn't always work. Sometimes a machine will be offline when it should be deleting the user.
> 
> And of course we need a phased introduction. If I can produce a tool that solves 80% of the problem that is 100% backwards compatible with the legacy world and
> get 100K people to use it, I can probably get the protocol/application changes I need to get the other 20%.
> 
> 
> The 80% problem is provisioning, credentialing and revoking keys.
> 
> I am not an SSH expert, I really need help here. But this is the sketch I have come up with to apply the Mesh to save the appearances.
> 
> We have an enterprise 'example.com <http://example.com>' and a set of the usual users Alice, Bob, Carol, Ingrid, etc. 
> 
> 1) Create an SSH CA for each individual user with the signature key for the CA threshold shared between the user's device(s) and the service sshca.example.com
> <http://sshca.example.com>.
> 
> 2) Configure the SSH daemon on each machine to only accept logins for each of the users if and only if they are signed by the assigned CA.
> 
> 3) Design a small protocol that allows a user to obtain an SSH cert from sshca.example.com <http://sshca.example.com> from a device the user has connected to
> their personal Mesh. This functionality can be added into the line mode meshman tool.
> 
> 
> To onboard a user, we have to:
> 
> 1) Create a user account on each of the machines they are authorized to access
> 2) configure the SSH daemon for the machine
> 3) Add the config for the users CA to sshca.example.com <http://sshca.example.com>. 
> 
> [This process can also be thresholded so we can stop Insider threat Ingrid doing this after she is fired. We can also script it, etc.]
> 
> Each n days, Alice will:
> 
> 1) Run meshman to create a new short lived cert and revocation token for the key on her device.
> 
> To terminate a user we:
> 
> 1) Tell sshca.example.com <http://sshca.example.com> not to issue any more certificates.
> 2) Distribute the revocation token to all the endpoints.
> 3) Tell each host to remove access to their account(s).
> 
> 
> If I am able to insert code into the daemon, I can lock this down further so that the daemon is reporting all the active users on the machine in realtime to
> some service and will kick any user off if sent an authorized command.
> 
> Comments? Ideas? Anything I missed? Is there an easier way to do this? Am I relying on features not widely supported?
> 
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/