Carthage Update Error: "Github API Request Failed: Bad Credentials"

Carthage update error: GitHub API request failed: Bad credentials

I got the solution in response to a Carthage issue I raised:

  1. Edit ~/.gitconfig and add the following:


    [credential]
    helper = osxkeychain
    [credential "https://github.com"]
    username = willhains

    (Replace willhains with your GitHub user ID.)

  2. Clone a private repo via HTTPS.

  3. OSX will prompt for your GitHub password.

  4. Run carthage update.

Carthage error Bad credentials

I got the solution in response to a Carthage issue willhains raised:

  1. Edit ~/.gitconfig and add the following:

    [credential]
    helper = osxkeychain
    [credential "https://github.com"]
    username = willhains

    Replace willhains with your GitHub user ID.

  2. Clone a private repo via HTTPS.

  3. OSX will prompt for your GitHub password.
  4. Run Carthage update.

OR

You can delete the GitHub credential form you Keychain access and use..

Hope this will help

go get results in 'terminal prompts disabled' error for github private repo

go get disables the "terminal prompt" by default. This can be changed by setting an environment variable of git:

env GIT_TERMINAL_PROMPT=1 go get github.com/examplesite/myprivaterepo

Git error: Host Key Verification Failed when connecting to remote repository

You are connecting via the SSH protocol, as indicated by the ssh:// prefix on your clone URL. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.

The host key for domain.example has changed. If this does not seem fishy to you, remove the old key from your local cache by editing ${HOME}/.ssh/known_hosts to remove the line for domain.example or letting an SSH utility do it for you with

ssh-keygen -R domain.example

From here, record the updated key either by doing it yourself with

ssh-keyscan -t rsa domain.example >> ~/.ssh/known_hosts

or, equivalently, let ssh do it for you next time you connect with git fetch, git pull, or git push (or even a plain ol’ ssh domain.example) by answering yes when prompted

The authenticity of host 'domain.example (a.b.c.d)' can't be established.
RSA key fingerprint is XX:XX:...:XX.
Are you sure you want to continue connecting (yes/no)?

The reason for this prompt is domain.example is no longer in your known_hosts after deleting it and presumably not in the system’s /etc/ssh/ssh_known_hosts, so ssh has no way to know whether the host on the other end of the connection is really domain.example. (If the wrong key is in /etc, someone with administrative privileges will have to update the system-wide file.)

I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.

GitHub: invalid username or password

https://git@github.com/eurydyce/MDANSE.git is not an ssh url, it is an https one (which would require your GitHub account name, instead of 'git').

Try to use ssh://git@github.com:eurydyce/MDANSE.git or just git@github.com:eurydyce/MDANSE.git

git remote set-url origin git@github.com:eurydyce/MDANSE.git

The OP Pellegrini Eric adds:

That's what I did in my ~/.gitconfig file that contains currently the following entries [remote "origin"] url=git@github.com:eurydyce/MDANSE.git

This should not be in your global config (the one in ~/).

You could check git config -l in your repo: that url should be declared in the local config: <yourrepo>/.git/config.

So make sure you are in the repo path when doing the git remote set-url command.


As noted in Oliver's answer, an HTTPS URL would not use username/password if two-factor authentication (2FA) is activated.

In that case, the password should be a PAT (personal access token) as seen in "Using a token on the command line".

That applies only for HTTPS URLS, SSH is not affected by this limitation.



Related Topics



Leave a reply



Submit