On Tue, Nov 22, 2016 at 6:12 AM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > Dennis Gilmore wrote: >> koji authentication will be switching to Kerberos. Koji supports multiple >> authentication mechanisms. Fedora infrastructure has set up a freeipa >> instance internally that has credential syncing to fas. We are working on >> ensuring that gssapi caching is supported so that you can have multiple >> TGT's and the ability to work in multiple reams at once. you can get >> started today by doing kinit <fas username>@FEDORAPROJECT.ORG if you move >> your ~/.fedora.cert file out of the way authentication will still work. > > Maybe a crazy idea, but couldn't Koji just use our SSH keys for > authenticating somehow? Those just work without any extra setup, they never > expire, and unlocking passphrase-protected keys is also an already solved > problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that > would have to happen is to tunnel the Koji CLI's communication through SSH > to koji.fedoraproject.org or to some trusted tunnel server that you can > delegate authentication to. Well the koji web interface itself doesn't use authentication anymore, from a fedpkg PoV there's a lot of complexity with http(s) because it could be proxied or NATed (worst is CG-NAT) so the same connection from the same laptop might not even come via the same IP. Basically what you're describing is exactly what kerberos solves, tokens to authenticate various different connections. A lot of companies and data security standards explicitly disallow ssh keys because of the fact it's client side pass phrases with no way to enforce a policy so there's no way to tell even if the key has a passphrase. Personally I'd like to see eventually the move to kerberos to replace ssh-keys as it's easier to enforce a minimum policy and manage. Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
