[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.