[Cryptography] Applying the Mesh to do SSH really right

Phillip Hallam-Baker phill at hallambaker.com
Sat Oct 23 14:17:11 EDT 2021


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?

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' 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.

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 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.

[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 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20211023/84676523/attachment.htm>


More information about the cryptography mailing list