openssh unix dev - Sep 2018 - add keys and certificate to forwarded agent on remote host

On 18/09/18, Tim Jones (b631093f-779b-4d67-9ffe-5f6d5b1d3f8a at protonmail.ch)
wrote:
...
> So issue your users with Yubikeys.  You can enforce the Yubikey so it
> requires the user to enter a PIN *and* touch the Yubikey.  This means
> there's an incredibly high degree of confidence that it was the user
> who performed the actiion (i.e. two-factor authentication of physical
> Yubikey and PIN, plus anti-keylogger because of the mandatory touching
> of the Yubikey).
I've been meaning to try a Yubikeys. As I understand it that would help
ensure that the user is the person they should be.

What is nice about runtime certificate issuance is that certificates can
be tuned for particular per-user, per-instance use cases, such as "root
on all DC1 webservers".

Unless I've misunderstood, verification of the user and the permissions
they have for potentially many roles on many servers are quite different
things.

Thanks very much 
Rory

> What is nice about runtime certificate issuance is that certificates can
> be tuned for particular per-user, per-instance use cases, such as
"root
> on all DC1 webservers".
>
> Unless I've misunderstood, verification of the user and the permissions
> they have for potentially many roles on many servers are quite different
> things.

Possibly the other question you need to be asking yourself is whether you're
abusing SSH, trying to make it do another tool's job ?

e.g sudo/doas for "root on a server", or kerberos+LDAP or similar.

Apologies if I'm teaching granny to suck eggs here, or my understanding of
SSH is all wrong.  But surely SSH certificates were only ever intended to be for
authentication, not for authorization ?

Look at Amazon AWS for example.  You can *authenticate* to their services using
SSH, but the whole *authorization* logic is controlled through AWS IAM.

Surely, if anything the AWS-style system is the one you should be looking to
replicate ? As that is obviously a methodology that has been proven to scale ?

On 18/09/18, Tim Jones (b631093f-779b-4d67-9ffe-5f6d5b1d3f8a at protonmail.ch)
wrote:
> > Unless I've misunderstood, verification of the user and the
permissions
> > they have for potentially many roles on many servers are quite
different
> > things.
> 
> Possibly the other question you need to be asking yourself is whether
> you're abusing SSH, trying to make it do another tool's job ?
> 
> e.g sudo/doas for "root on a server", or kerberos+LDAP or
similar.
> 
> Apologies if I'm teaching granny to suck eggs here, or my
> understanding of SSH is all wrong.  But surely SSH certificates were
> only ever intended to be for authentication, not for authorization ?
> 
> Look at Amazon AWS for example.  You can *authenticate* to their
> services using SSH, but the whole *authorization* logic is controlled
> through AWS IAM.
> 
> Surely, if anything the AWS-style system is the one you should be
> looking to replicate ? As that is obviously a methodology that has
> been proven to scale ?
Sure, the logic behind certificate issuance is based around
authorization.

In a small, open-source environment (i.e. no dependencies on AWS or
similar external providers) what authorization system would you
recommend that deals with users, roles and machines? Ideally it would
plug into openssh.

On Tue, 18 Sep 2018, Tim Jones wrote:
> Apologies if I'm teaching granny to suck eggs here, or my
> understanding of SSH is all wrong. But surely SSH certificates were
> only ever intended to be for authentication, not for authorization ?
certificates contain several built-in authorisation features (extensions
and critical options) and the supporting configuration options
AuthorizedPrincipalsFile and AuthorizedPrincipalsCommand are often
used to implement authorisation schemes.