On 2018-08-21T14:48, Stef Bon <stefbon@xxxxxxxxx> wrote: > Op di 21 aug. 2018 om 14:43 schreef Alexander Wuerstlein <arw@xxxxxxxxx>: > > > > On 2018-08-21T06:21, Stef Bon <stefbon@xxxxxxxxx> wrote: > > > > The user dos not do that, the localhost computer does this behind the scenes. > > > > Sounds like you are reinventing Kerberos. > > > > Thats good! Kerberos is proof of concept. > But serieus, Uber does it like this (or simular< see: > https://medium.com/uber-security-privacy/introducing-the-uber-ssh-certificate-authority-4f840839c5cc) There are huge differences to what you described. First, Uber uses just SSH, you mentioned e.g. internet access or print services which aren't easily SSH-tunneled without tons of headaches. Kerberos is already integrated into file services like NFS, SMB or WebDAV, print services like LPR or IPP and proxy servers like Squid. You just have to enable it and it will work. Whereas with SSH, you could tunnel all that, but you will have to adapt all the mentioned client services for that. And you get additional problems because the SSH-Tunnels authentication is not bound to the authentication of the inner protocol (say IPP), which means that you have yet another set of authentication credentials or none at all. All of which makes authorisation problematic or broken, except in the most trivial case (where you only have the two classes "is allowed everything" and "is denied"). Second, the article describes an automatic SSH-CA for longer-lived keys, e.g. "If an employee loses access (e.g. they leave the company)". What you describe is intended as per-session-keys, which has another ton of headaches, because of short expiry periods and frequent key changes. It's doable, but not very easily, because sessions start and end all the time, and their expiry isn't just given by an expiry date in the SSH-Certificate (decentrally checked by each sshd) but by the user exiting the session (centrally signalled to the magic session db and then read/polled/waited for by all services using the session). Also, authentication is just performed using the SSH-key in Uber's case, you intend to pass around the password as well which is a really bad idea. Passwords should never be cached, remembered or passed around, decades of experience show that this will only lead to compromise. Ciao, Alexander Wuerstlein. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
