Authenticate private github repository using https

Question

I created a private repo on github and tried to set it up as my remote of a local git repository. However, when the remote is set to the default https address (https://github.com/...), using git push gives me error "Error: Repository not found". After googling around, I tried using (https://username@github.com/...), but that gave me "Failed to connect to gitHub.com port 443 : Connection Refused."

So finally I tried using the ssh method, which works, after setting up the ssh key and stuff. So what was I doing wrong with the https setup? I didn't have this kind of problem with public repos.

Answer 1

To expand on merlin2011's comment, check your git credential helper:

git config credential.helper

On Windows, for instance, it should be the Windows Credential Manager, which would cache your credentials.

---

With Git 2.46 (Q3 2024), rc0, the http transport can now be told to send request with authentication material without first getting a 401 response.

In short, it works for public repositories too, not just private ones.

See commit 610cbc1 (10 Jul 2024) by brian m. carlson (bk2204).
^{(Merged by Junio C Hamano -- gitster -- in commit fe5ba89, 16 Jul 2024)}

http: allow authenticating proactively

^{Signed-off-by: brian m. carlson}

When making a request over HTTP(S), Git only sends authentication if it receives a 401 response.
Thus, if a repository is open to the public for reading, Git will typically never ask for authentication for fetches and clones.

However, there may be times when a user would like to authenticate nevertheless.
For example, a forge may give higher rate limits to users who authenticate because they are easier to contact in case of excessive use.
Or it may be useful for a known heavy user, such as an internal service, to proactively authenticate so its use can be monitored and, if necessary, throttled.

Let's make this possible with a new option, "http.proactiveAuth".
This option specifies a type of authentication which can be used to authenticate against the host in question.
This is necessary because we lack the WWW-Authenticate header to provide us details; similarly, we cannot accept certain types of authentication because we require information from the server, such as a nonce or challenge, to successfully authenticate.

If we're in auto mode and we got a username and password, set the authentication scheme to Basic.
libcurl will not send authentication proactively unless there's a single choice of allowed authentication, and we know in this case we didn't get an authtype entry telling us what scheme to use, or we would have taken a different codepath and written the header ourselves.
In any event, of the other schemes that libcurl supports, Digest and NTLM require a nonce or challenge, which means that they cannot work with proactive auth, and GSSAPI does not use a username and password at all, so Basic is the only logical choice among the built-in options.

Note that the existing http_proactive_auth variable signifies proactive auth if there are already credentials, which is different from the functionality we're adding, which always seeks credentials even if none are provided.
Nonetheless, t5540 tests the existing behavior for WebDAV-based pushes to an open repository without credentials, so we preserve it.
While at first this may seem an insecure and bizarre decision, it may be that authentication is done with TLS certificates, in which case it might actually provide a quite high level of security.
Expand the variable to use an enum to handle the additional cases and a helper function to distinguish our new cases from the old ones.

git config now includes in its man page:

http.proactiveAuth

Attempt authentication without first making an unauthenticated attempt and receiving a 401 response. This can be used to ensure that all requests are authenticated. If http.emptyAuth is set to true, this value has no effect.

If the credential helper used specifies an authentication scheme (i.e., via the authtype field), that value will be used; if a username and password is provided without a scheme, then Basic authentication is used. The value of the option determines the scheme requested from the helper. Possible values are:

• basic - Request Basic authentication from the helper.
• auto - Allow the helper to pick an appropriate scheme.
• none - Disable proactive authentication.

Note that TLS should always be used with this configuration, since otherwise it is easy to accidentally expose plaintext credentials if Basic authentication is selected.