Mix fails to clone from GitHub over HTTPS via 'mix deps.get'

Questions / Help
, ,
1

I have successfully cloned this repository over ssh:

git clone irleif@github.com:ueberauth/ueberauth_example.git

When I try to get dependencies with mix deps.get, I get this error:

* Updating oauth (https://github.com/tim/erlang-oauth.git)
fatal: unable to access 'https://github.com/tim/erlang-oauth.git/': Couldn't connect to server

I can see that ueberauth_example is including erlang-oauth in its mix.exs, in this way:

{:oauth, github: "tim/erlang-oauth"}

The dependency doesn’t specify https or ssh, so I presume mix is defaulting to https.

However, I am able to clone the repo just fine manually over ssh, like this:

git clone irleif@github.com:tim/erlang-oauth.git

Is it somehow possible to make mix deps.get use ssh for cloning instead of https?

2

Aha! I recently enabled two-factor authentication, which might be why this is happening:

If you have enabled two-factor authentication, or if you are accessing an organization that uses SAML single sign-on, you must provide a personal access token instead of entering your password for HTTPS Git. (Source)

You can create a personal access token and use it in place of a password when performing Git operations over HTTPS with Git on the command line or the API. (Source)

I wasn’t aware of that until now.

Since GitHub recommends HTTPS over SSH, I’ll get that working instead.

Edit:

So, I fixed two-factor authentication, and the problem still persisted. After much head-scratching, I decided to try in Apple’s “Terminal” app, instead of iTerm.

Lo and behold; cloning over HTTPS worked like a dream.

After some more digging, I found the culprit: The app “Little Snitch” (network filter) was blocking iTerm. Adding an exception to the network filter was all I needed to do :laughing:

3 Likes
3

I know it’s been years but I’m going to chime in here as well just in case anyone runs into the specific issue I was having…

Any git SSH commands started prompting me for my key’s password every time despite having already added my key to an agent via ssh-add.

Then I remembered that earlier today I was setting up the 1Password CLI and configuring it for SSH. Part of the instructions say to add something like:

Host *
  IdentityAgent "~/Library/Group Containers/12345ABCDEF.com.1password/t/agent.sock"

To your SSH config file: ~/.ssh/config

The rest of my SSH config looked like this:

Host *.github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Host *.gitlab.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

So my silly self had inadvertently told SSH to always go through the 1Password socket for every host… :man_facepalming: I commented that out and now I’m good to go…