add headless support to [step ssh login ..]

[tmcolby]

What would you like to be added

The step oath command can be called with --console when headless. It would be useful to be able to pass this argument when doing step ssh login <user> --issuer <some oidc provisioner>

Why this is needed

I could be mistaken, but I think the step ssh login .. automates the oauth flow. For example, I can do

TOKEN=$(step oauth --client-id <client_id> --client-secret <client_secret> --provider https://accounts.google.com/.well-known/openid-configuration --oidc --bare --console)
step ssh login <identity> --token $TOKEN

to achieve what I want when working on a headless host. We should be able to pass the --console argument to step ssh login .. to achieve the same result

[tmcolby]

Similarly step ca token <subject> --issuer <some oidc provisioner> should accept the --console argument. I suppose, more generically, anywhere you select an oidc provisioner one should be able to not leave the shell by passing the argument.

[tmcolby]

If you cal step oauth without any other arguments it uses client_id=1087160488420-8qt7bavg3qesdhs6it824mhnfgcfe8il.apps.googleusercontent.com which is owned by smallstep. Is this a bug/error? For the sake of generic and opensource, shouldn't the command consult my CA at --ca-url for a default oath url instead of hitting a smallstep owned provisioner?

[mmalone]

Yea, the step ssh login and step ca token (and step ca certificate) commands run step oauth if you're using an OAuth OIDC provisioner. We should probably add the --console flag to these commands. Initially I was going to ask why you wouldn't just run step ssh login ... --token $(step oauth --console ...), but then I realized there's no easy way to get the OAuth configuration details from the CA down to the step oauth command. So I guess this is needed.

If you cal step oauth without any other arguments it uses client_id=1087160488420-8qt7bavg3qesdhs6it824mhnfgcfe8il.apps.googleusercontent.com which is owned by smallstep. Is this a bug/error?

This is by design. This client is scoped such that the OAuth access token can't be used for anything. The OIDC identity token is audience-addressed and the callback is set to 127.0.0.1. So the only way to get a token using this client is to be running locally on a machine. It's subtle, and it's been a while since we threat modeled this, but the flow has essentially the same security characteristics as any other OAuth flow.

The advantage, then, is that you can safely use this client for authenticating using G Suite + OIDC without having to go through the process of creating your own. So it's a simple expediency for some use cases.

For reference, this is following BCP for OAuth 2.0 Native Apps. It's also the same thing that Google's gcloud command-line tool does. So it's pretty standard and there's reputable prior art.

For the sake of generic and opensource, shouldn't the command consult my CA at --ca-url for a default oath url instead of hitting a smallstep owned provisioner?

Maybe, but step in general doesn't require that you have a CA running. In particular, step oauth doesn't need a CA. This could be a nice feature to add to step oauth, however, and it could solve the problem from above without requiring the --console flag on other subcommands... would that work for you?

[tmcolby]

Hi, Mike, thanks for your feedback. Yes, this:

but then I realized there's no easy way to get the OAuth configuration details from the CA down to the step oauth command.

Short of scraping step ca provisioner list, there is no easy way at the moment.

Either the above, or adding --console on the other subcommands could solve for the issue. My preference, for sake of a straightforward workflow and simplicity (in my opinion), would be to have the ability to run step ssh login ... --console. Otherwise, for my use case, I will need to create a custom login script or alias to achieve the same thing. It would be nice and tidy if step-cli did this out of the box though. I imagine as the project grows, eventually, both approaches will get solved for ;)

-Thanks, Tyson Colby

[maraino]

Hi @tmcolby, we are going to add the --console flag, but there's a trick that you can use right now. If you set the environment variable STEP_CONSOLE=true it will force --console to be set:

STEP_CONSOLE=true step ssh login jane@doe.com

[tmcolby]

Great.. thanks for the hack @maraino . I just tried this and it works as you stated.