5 ms·

Another trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is th

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

dig1 3y ago
Nice trick! I'd usually set alias in ~/.ssh/config and set origin to match that alias, e.g. Host project-foo Hostname github.com User git IdentityFile ~/.ssh/some_key Then I'll pull the project with: git clone project-foo:/Foo/project.git
crabbone 3y ago
What's the reason to want SSH over HTTPS for Git? 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?
- Joker_vD 3y ago
  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.
  - crabbone 3y ago
    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.
    - Joker_vD 3y ago
      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 3y ago
        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.
        3y ago
- Hackbraten 3y ago
  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.

dig1 3y ago

Nice trick! I'd usually set alias in ~/.ssh/config and set origin to match that alias, e.g. Host project-foo Hostname github.com User git IdentityFile ~/.ssh/some_key Then I'll pull the project with: git clone project-foo:/Foo/project.git

crabbone 3y ago

What's the reason to want SSH over HTTPS for Git? 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?

Joker_vD 3y ago
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.
- crabbone 3y ago
  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.
  - Joker_vD 3y ago
    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 3y ago
      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.
      - 3y ago
Hackbraten 3y ago
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.