Another trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is the "Match exec" directive which allows you to include a shell (bash) conditional (such as a directory-check), e.g.
Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/work/* ]]"
IdentityFile ~/.ssh/keys/work
User me-work
Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/personal/* ]]"
IdentityFile ~/.ssh/keys/personal
User me
Genuinely curios. After HTTPS became supported I never looked back. The whole authentication management and Git remote URL syntax are a huge mess I'd never want to touch unless forced to. HTTPS makes it a lot simpler... at least for me. Am I missing something?
I personally never managed to make pushes work over HTTPS, while with SSH it works the moment clone/pull works. Plus I vaguely remember that setting up HTTP auth was way more cumbersome that SSH auth.
Are you talking about server-side configuration or client-side?
I haven't had to set up Git server in a very long time. I'm not even sure if I had to set up HTTPS authentication for it. But, I can see how this may be potentially more difficult as you'd already have SSH set up for accessing the server by the time you get to set up Git.
It's been a lot easier on the client-side though. Especially having to deal with multiple users / multiple servers and having to share configuration between different machines. Usually it just boils down to having ~/.git-credentials and if necessary, adding a similar file in the root of the repo.
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.
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):
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.
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.
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.
> 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.
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...
I avoid HTTPS for Git because I prefer not to have credential secrets sitting around unencrypted in my home directory. For SSH, I keep my private key on my Yubikeys.
Shoutout for The Old Reader (https://theoldreader.com/) as a great online RSS reader ($20 per year) which sprung up in response to Google Reader shutting down and is still going strong.
There also appear to be elements from this question, such as the report method ([2]), but it's definitely been adapted (or there's a different source):
It uses the (n)vim remote API with tmux to maintain a global (n)vim session and redirects files opened via `vmux` back to the global session and switches to the window in tmux that session is visible in.
Hints:
- use `pipx` [2] to install `vmux` to make it available globally so you don't need to mess around with virtual environments.
- just `alias nvim=vmux`, and use `command nvim` if you need the real thing.
- I set the following in my profile file:
export VMUX_EDITOR="nvim"
export VMUX_GLOBAL="true"
alias nvim=vmux
This reminds me of the sadly defunct Automaten (http://www.automatenbar.de/) in Berlin from the early 2000s.
This was a members-only club (I think it was like 10 euro per year) that was a hacker and party space, accessible only if you had a mag-strip card, and completely hidden in plain sight.
Inside was a number of pre-euro vending machines (automats) that required you to use Automarken (not coincidentally the same size and weight as the Deutschmark coin). Inside the automats, apart from snacks and drinks, were an eclectic mix of handmade items that you could buy - a bit like a physical Etsy.
I use vmux (https://github.com/jceb/vmux/) to redirect all files opened for editing (via nvim some_file.ext) from any tmux window to a single Neovim session.
I've started going straight to Wikipedia and searching there if I know I'm going to end up there anyway for the same reason, plus I deny Google the search data and ad-serve
Not exactly pop, but there are some great weekly music podcasts that I listen to to hear new music, which tend to be a little more indie pop/rock/${genre} than pop :)
Can definitely recommend FastMail - I migrated from Gmail around 4 years ago and haven't looked back
It has a clean, powerful UI with good shortcuts. DNS management and basic site hosting (with automatic Let's Encrypt support), great calendar and contacts support.
Had some problems with some senders getting rate limited a while back, but worked with support to get it fixed up.
