[tossaway9000]

> Create an SSH key pair for the user.

> Send the user their private key via 1Password.

Why are you generating *private keys* for users, then sharing them? Not that this impacts the automation bits but IMHO users should known how to generate and maintain a key pair, and send you the public key.

[renewiltord]

Did it all the time. Users weren’t sophisticated. They want a tool they can put a user/pass into and then upload and download. They have maybe some conditions from IT (SFTP okay, S3 okay, encrypted at rest, whatever).

We did this trivially with S3, our implementation guy gives them an access key ID and secret access key, tells them to install Cyberduck, and gives them a URL to paste. We’re off to the races.

Having the user generate the thing will turn going live from hours to days.

I’ve also done this analogously with SFTP. You keep the creds so you can help them because they’ll type it in wrong, their software will fuck it up, whatever.

[iso1631]

Agree, it's painful, and it really takes me out of the larger point they are trying to make

A workflow should be be

    User creates an SSH key pair, the private key never leaving the computer
    User sends public key to authoriser
    Authoriser pushes public key to Git (presumably an email + key touple?)
    Wait for the build job to finish (not sure what this does)
    Build process sends the email saying "You can now use your key"

Same with say a wireguard key. Or an SSL certificate.

I think the larger point is that you just have step by step instructions, and thus dont need to catch edge cases, but it also makes it harder to avoid skipping a step, which seems reasonable (I do this myself in some areas)

[hollasch]

Not to weigh in on this particular issue, but I think your objection here is another piece of evidence weighing in the favor of this overall approach. It's perfect to have this debate immediately and so early in the process, before any time is spent in detailed implementation.

[DantesKite]

Why?

[tossaway9000]

It's not a "private" key if its shared. Only the end user needs to know the private key details.

Consider the usecase of generating a user their initial password for a service, this almost always results in the user needing to immediately reset their password after initial login, this doesn't happen if someone is generating both parts of the key pair for you.

My sysadmin doesn't need to know my password, and doesn't need to know my private key or passphrase, that would allow them to impersonate me.

[ghostly_s]

well, your sysadmin created your AD account, and probably has some means of root access to your box too, so they could already impersonate you. *

*this may or may not be true depending on how Enterprise-y your workplace is.

[chousuke]

The difference is in the kind of audit trail it leaves. If a sysadmin impersonates a user, that leaves a different kind of trail than a user logging in with their own key that only they can access.

In principle, the sysadmin should explicitly avoid knowing any of the user's secrets, because if they do, the user can shift blame onto them: "It wasn't me, it was the admin!".

I will never generate a private key for a user and will initiate a reset process for any passwords and other personal secrets revealed to me; to do anything else would be irresponsible.

[nerdponx]

If nothing else, they need to be able to access your files in case you leave.

[lucb1e]

Unless it's all encrypted with the user's own password: sure, you can always invoke the admin powers and override the password field in the database or whatever. But the default mode should be that an account is only accessed by the person it belongs to.

Even as a security firm we have some exceptions in our company (disk encryption password for a physical device in the office is in a shared vault, for example), or support might do a remote control session with the user present, but it's definitely not the default setup procedure for a new employee to have shared credentials for example.

[chousuke]

I think it should be noted that even with with encrypted data you'll generally just encrypt the master key with multiple passphrases; one (or more) master keys for admin use and one for the user themselves. There's really very rarely a good reason to share any secrets.

It's pretty much a necessity for any larger business that device data be protected with the user's own password and with a master password known to IT so that it can be accessed when the user's password is inevitably lost.