News for hackers. Stuff that matters.
Re:The default OpenSSH key encryption is worse than plaintext by otterley on Saturday August 04, 2018 @11:58AM (#17687322)
Out of curiosity, how can you have individual user logins on a host while delegating authn/authz to a CA? All the examples I've seen thus far involve a shared login, whereas I find it's a lot easier to audit hosts when a unique user ID is in the logs, last/w/who output, etc.
Re:The default OpenSSH key encryption is worse than plaintext by gdamjan1 on Saturday August 04, 2018 @12:33PM (#17687475)
bless allows to specify the remote user in the certificate. you'll need to customize the certificate issuing program (a small python lambda program)
Re:The default OpenSSH key encryption is worse than plaintext by otterley on Saturday August 04, 2018 @01:32PM (#17687710)
I think I need some more information. What I'd like to do is to have a signed certificate that only lets me into the "otterley" account on the remote host, while not letting "jsmith" into my account (only hers) or vice versa.

My understanding of CA principals is that they identify the user or role that requested the signing, but not necessarily the login ID on the server that is allowed to be logged into. Ideally there'd be a 1:1 mapping between the principal and the login ID on the server. I think there's some sshd configuration that needs to be done, but I haven't seen any clear instructions for doing so.

Do you know how to accomplish this?

Re:The default OpenSSH key encryption is worse than plaintext by e12e on Saturday August 04, 2018 @02:03PM (#17687821)
Have a look at eg:

https://linux-audit.com/granting-temporary-access-to-servers...

And re-read the (imnho rather obtuse) ssh-keygen man pages.

[ed: and maybe this too: https://framkant.org/2017/07/scalable-access-control-using-o... ]

Re:The default OpenSSH key encryption is worse than plaintext by otterley on Saturday August 04, 2018 @04:40PM (#17688341)
Thanks! So it looks like AuthorizedPrincipalsFile/AuthorizedPrincipalsCommand gives us a method for doing this. This would have to be combined with some sort of user ID management system still, like distribution of /etc/{passwd,group} files, LDAP/AD, etc.
Re:The default OpenSSH key encryption is worse than plaintext by e12e on Saturday August 04, 2018 @08:46PM (#17689127)
There's also: https://github.com/uber/pam-ussh/blob/master/README.md

https://medium.com/uber-security-privacy/introducing-the-ube...

And for the ssh ca part, bless and teleport (as others have mentioned).

There's the option of putting stuff in ad/ldap - but if you're already using ad, kerberized ssh (and sudo etc) might be the way to go.

I like the idea of a system that's simpler than ad/ldap+kerberos - and ssh certs fits most of the bill.

The challenge becomes auth/authz beyond just login - ldap basically requires ssl ca anyway - and at that point, especially with kerberos set up - I think one might be better off sticking with one complex auth/authz system rather than two...

At least it should be possible to avoid passwords with something like: https://wiki.freeradius.org/guide/2FA-Active-Directory-plus-...