Adding SSH keys currently requires MFA in all cases, so we'll have to figure out what the rules are here.

For upstream stuff, we currently use a single shared key rather than a key-per-VM, but this may not be a good fit in all cases.

I don't understand this use case. Why do you have unique keys per-VM?

Because they're developer machines VMs, we want pushes to be recognized as that developer, so they have the correct policies applied.

Aha, so the users are also different, and they're real users (not bots)?

I'm not sure this feature makes sense in the upstream. Adding an SSH key to a different user's account without their permission is approximately the same as just taking over their account, and is at odds with the philosophy of limited administrative access.

Or are you already impersonating them somehow (how are you getting the Conduit tokens/certificates?) and want to do a self-add as them?

We're already impersonating them; we do the standard arc install-certificate process to configure Arcanist, and then we want to automatically configure SSH access afterwards. This is to make configuration of a developer's machine only require one manual step (authenticating with Phabricator for Arcanist).

There are two use-cases here:

• On Windows, going from a fresh install to a full development environment with Git, Arcanist, Visual Studio etc all installed. Windows is reasonably difficult to configure everything correctly, so we use a PowerShell script to configure the developer's environment for them.
• Spinning up AWS EC2 virtual machines for the few Linux projects we have (in this case we also have the developer's API token since the EC2 machine is being spun up from one of the Windows machines configured in the first use case).

If users have MFA configured, I think it's important that we not let an attacker avoid MFA checks on operations (including adding SSH keys) by using Conduit. So if we had a method for adding SSH keys we'd either have to deactivate it when we hit an MFA block, or implement CLI MFA somehow (seems tricky/complex?) or have it add a "request" and then require the user to confirm that they want to add the key via MFA from the web UI after passing MFA, maybe (this feels bad to me for a bunch of reasons, though).

These also all feel sort-of worse to me than, say, printing out the public key to the console an telling them to go plug it into the web UI, although that isn't great either.

We could also possibly let Conduit tokens authenticate SSH, although you'd have to run a modified sshd for this to work (we have such an sshd already, but this feels like a whole mess of badness).

This is relatively straightforward to implement in an extension, although you'll have fewer options on the MFA issue. The MFA issue makes this feel like a very awkward fit for me in the upstream. We have no other Conduit MFA use cases right now that I'm aware of and no other installs interested in this use case.

You can't add Conduit tokens without MFA though right?

We could allow Conduit tokens to perform SSH key configuration for a short period after they're created.