Non-OAuth auth sources

[lyda]

I was thinking a PAM-based auth source and possibly some sort of machine-based auth would be nice.

There are certain situations where I'm in an interactive session and I'd like to get an ssh cert but lack a browser. There's obviously this way but I'm wondering if a cashierd that supports PAM auth would be an option?

It would also be nice to have a way for things like periodic jobs to be able to request an ssh key. But not really clear on how that would exactly work that would be much better than just putting ssh keys there to begin with.

[nsheridan]

I haven't figured out how I'd like to manage host certificates. This sounds like it would be an option.

[nsheridan]

There's a few things to consider wrt PAM modules.

• It'll probably require using CGO to wrap some things
• How will challenges (e.g. 2fa) be interpreted and passed to the client?
• Would it be worth implementing providers as needed? e.g. ldap provider, krb5 provider...
• I wonder what it would take to support multi-factor with Duo (https://github.com/duosecurity/duo_api_golang) or U2F (https://github.com/marshallbrekka/go-u2fhost)

[lyda]

Re: PAM. Yes, I suspect cgo would be needed. The Go PAM lib I found did seem to have a C component.

Re: authentication conversation between client and server. One way might be for the server to tell the client a list of things to request (thing, prompt for thing, should it be echoed), and a url to send them back to once they are all collected. Alternatively it could be a back and forth, but that seems to give more information away. Regardless conversations should have timestamps and the server should reject responses that come back too quickly - possibly growing such delays for repeat failures.

Getting a security review of something like that would be good however.

Re: implementing as needed. An initial pass could just have an implementation done entirely within the server - it maintaining a list of users, password and OTP secrets just to test out the conversation. Advancing to external methods like PAM. ldap, Kerberos, etc opens up thoughts about plugins since not everyone would need each of these. Some way to punt to an external authenticator.

Re: multi-factor. Well, I already looked at the TOTP/HOTP libs and they seemed simple enough. I was planning on doing an internal implementation using that.

[nsheridan]

I totally agree with implementing as needed, and yeah the small version is a static list of usernames/passwords and building on that.

I'm currently experimenting with adding grpc to cashier, and I think/hope it'll be a bit less nasty to handle auth there (http://www.grpc.io/docs/guides/auth.html) rather than resorting to stuff like basic auth and checking headers. I think this will also make it easier to perform machine-level auth.
I wanted to do this from day one but grpc isn't quite stubby and doesn't have a http listener with an rpc switch, and so a single port handling both grpc and http isn't possible out of the box. I came across this recently though and it seems to work well: https://github.com/soheilhy/cmux.

[nsheridan]

I've added a first pass of a PAM auth option to cashier: https://github.com/nsheridan/cashier/compare/pam_auth

It needs some cleanup - it's hard-coded to use the login stack and there are no tests or docs.

[nsheridan]

Some considerations

• The admin interface (limited as it is) is accessed with oauth. Should this be configurable?
• Do we want multiple auth provider interfaces (an oauth provider, an ldap provider, a pam provider ....) or should everything be shoved into a single provider interface?

[lyda]

So I can think of some use cases if that helps. For me at home, I'd eventually like to use cashier to provide ssh keys for gitlab (with force-command set properly) and for other servers (w/o force-command set. This would mean two different ssh signing keys so maybe the answer is two cashiers running - and they'd both use the same auth source.

Having a text-only mode auth source would be good for ssh'ing from my phone. But again I can accomplish that with another cashier running.

As for the admin interface, I don't really use it, so not sure. How would that work with PAM auth is the question you're asking and I'm not sure.

[nsheridan]

Do you use the same accounts server-side for gitlab and not-gitlab?

I'd prefer to not require running multiple CAs for similar purposes but I'm reluctant to descend into a rat hole of making a general solution for all possible use cases either.

[lyda]

Yes. It's just that I need different keys - they need different options and they'd need different signing keys. The more I think of it they really should be separate CAs.

I could see similar issues for test machines and prod machines. Where pretty much anyone in an org could get keys signed by the certificate for test machines, but only those oncall could get keys signed by the production cert. But then that leads to the sshca not only checking oauth credentials, but also PagerDuty or whatever.

[vpm-bradleyhession]

Hi guys,

has there been any progress on being able to sign the key without 2fa? It would be nice to allow machines in our CI pipeline to request SSH keys.

Thanks,

[cannadayr]

I would also be interested in this. Currently im looking for a SSH version of cfssl that supports sqlite, and this meets the majority of my needs, however reliance on a 3rd party oauth server gives me pause.

PAM auth or being able to run my own oauth server in conjunction w this would be a great step in the right direction. Might even be willing to write a patch if i get more acquainted w the project.

[lyda]

There is the option of signing ssh keys manually.

[cannadayr]

If i have to sign the pubkey manually why use a service then?

[mrjk]

I would love to have this feature as well :)