[Joker_vD]

Client-side, of course. My password manager stores SSH keys and integrates with SSH seamlessly (it implements an ssh-agent), which took about 10 minutes to set up; I spent about an hour trying to integrate it with Git's own credential system to provide username-password pairs for HTTPS access and couldn't do it. So there.

[crabbone]

Well, nowadays the popular managed Git services provide you with a simple way of setting up HTTPS access: you go to some page that generates an "auth token" or something along those lines, depending on the service you use, and they give you the line you should put in your ~/.git-credentials file.

But even if they don't, here's an example for Bitbucket (we use self-hosted Bitbucket at work):

    https://$USER:$PASSWORD@bitbucket.$COMPANY.com%3a$PORT

and then in ~/.gitconfig

    [credential]
 helper = store

The ~/.git-credentials file may contain multiple lines, and it doesn't have the same problem with escaping as, say, ~/.netrc (because stuff that goes into it needs to be URL-encoded). Also, unlike SSH, it can use password-based authentication (you cannot put your SSH password into ~/.ssh/config). So, this solves the part where you want to authenticate to different Git repos.

And if you want to use different personalities for authenticating to the same repo, you can change the location of the ~/.git-credentials file per repo. I was never in a situation where I had more than two roles in the same repo, so, usually, I'd alternate between the global .git-credentials and local-to-repo one. If it becomes really annoying, I'd have two checkouts of the same repo, but with credentials configured for different users.

PS. I would never use a password manger because of trust issues. I don't like random programs having weird integrations with it. Plus, it usually fails to understand the context in which password is to be supplied (eg. tries to show a pop-up window where pop-ups don't work). I store the information I want to be secret encrypted with GPG with a key with a passphrase. I use Emacs to keep a buffer with this file open, if I need passwords and copy from it when necessary. This is less automated and takes extra few seconds to do things that require authentication, but having once lost my password manager database to an upgrade... I'm once burned twice shy.

[Joker_vD]

Or you can go to some another page, upload a public key, and then they also tell you that you should put such and such lines into your ~/.ssh/config file.

And no, I am not going to store passwords, or auth tokens, in an unencrypted plain text file thank you very much.

[crabbone]

> in an unencrypted

In my answer you replied to I suggested storing passwords in a GPG-encryped file. This also extends to .git-credentials (you can use GPG to encrypt it). I usually don't see a merit to that, but if the company policy is to keep such data encrypted, this is what I do.

I already described some of the downsides of ~/.ssh/config. Here are some others:

* You'd need to have the same private key on every computer you use. This is inconvenient, and raises the question of "how do I transfer my key?" And there aren't really good ways... Send with email? -- if your email is breached, then all your computers need to change keys quickly. Some kind of external storage? -- same thing when it's lost.

* I use SSH for a lot of things. I prefer that most things I needs SSH for on a particular computer use the default private key (so that I don't need to edit ~/.ssh/config every time I need to connect somewhere). In my line of work, on average, per day, I need to create couple dozens VMs which I then need to SSH to. Having to configure those to use a different key, even though these are throw-away VMs feels like too much of a chore.

There are downsides from the server admin perspective too. SSH, in general, will need a level of oversight inside an org to provision, expire, sign etc. the keys. Because SSH can, potentially, do a lot more things than HTTPS (when connecting to a server), admins need to be very careful giving SSH access only for the purpose of using Git. I.e. it's easy to give user actual Shell access (by accident) to the Git server instead of giving just Git access.

SSH can be very finicky when it comes to timeouts, encodings and a bunch of other options. But, still, my biggest problem with it is that it can do too much, and in the context of using Git it can bee too much by accident.

[Joker_vD]

> You'd need to have the same private key on every computer you use.

No you don't. You use different private keys on different computers, they are really not that expensive to mint. This also simplifies revocation.

> "how do I transfer my key?"

If you really, really need that, it's very simple: curl https://github.com/Joker-vD/keepassdb/raw/master/Joker_vD.kd...

> I prefer that most things I needs SSH for on a particular computer use the default private key

Okay? You use non-default keys for hosts that host git repos, everything else gets the default key. I actually use exactly this configuration: my ~/.ssh/config has 4 entries, 3 of them for git servers I have push access to, and the fourth one is for a personal VPS. Everything else gets offered ~/.ssh/id_rsa

> There are downsides from the server admin perspective too.

That's the server admins' problem, not mine.

> SSH can be very finicky when it comes to timeouts, encodings and a bunch of other options

Can't really relate here, maybe you're right. But in my experience, it either just works fine, or doesn't work at all, no middle ground. Also, "encodings"?

All in all, my experience have been that Git over SSH Just Works™ while Git over HTTPS has all kinds of strange problems, inlcuding half-assedly written HTTP-proxies somewhere in the middle.

[hprotagonist]

> (you cannot put your SSH password into ~/.ssh/config)

you can, however, use `ssh-agent` (and should!)

[crabbone]

Why do you believe anyone should use ssh-agent?

Well, if we expand arbitrary the range of programs reading ~/.ssh/config, then we can put there whatever we want, can't we? The point was that SSH won't read the password from its config file. There's a good reason not to do that: this configuration file shouldn't contain sensitive information because it's a plain text file. But, maybe you can encrypt it -- something I've never explored...