Is it possible to git push with HTTPS protocol?

Question

When I try to push to a repo I've cloned down via HTTPS protocol, it tells me to enter my username and password, then promptly errors with

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/pavelkomarov/repo.git/'

First of all, why on earth is the git client asking me for a username and password only to then tell me "Sorry, I don't accept those anymore, teehee "?

Second, is there even a way to push using HTTPS? I've only gotten push to work over SSH. Do you have to dig in to the git config and put some kind of key there, or is there literally just no path to do this anymore? If it's the former, it's so wildly is non-obvious how that I'm getting the impression it's the latter.

Third, why default to HTTPS when SSH is more functional? To me this is a case of Why do we even have that lever!?" Is it just that they don't want all users to have to do SSH key creation and adding, while expecting super users to be able to figure it out? But honestly it seems like my whole team has to do these steps anyhow!

They actually boil down to not that much:

1. cd ~/.ssh && ssh-keygen followed by cat id_rsa.pub | pbcopy
2. navigate on the website to user settings -> SSH and GPG Keys -> add key button -> paste -> green button to complete
3. make sure you're using the SSH protocol with git remote set-url origin git@github.com:user-name/repo-name.git

This is simple enough to describe in the client's error message, or at least to put as top-line items at that web article where the error message directs users.

I've run in to this nonsense several different times over the last few years, because honestly I don't set up git on a new machine often enough to remember all these steps, and the documentation around this is overly verbose and doesn't direct you to do the minimum viable set of actions to enable push.

Answer 1

First of all, why on earth is the git client asking me for a username and password only to then tell me "Sorry, I don't accept those anymore, teehee "?

When you cloned it, the repo's remote was initially set up as HTTPS, and you haven't changed the URL thereafter. Thus git asks for HTTPS auth details, tries to contact GitHub, and GitHub says "can't use those any more".

Second, is there even a way to push using HTTPS? Do you have to dig in to the git config and put some kind of key there, or is there literally just no path to do this anymore? If it's the former, it's so wildly is non-obvious how that I'm getting the impression it's the latter.

The link in the error message tells you how to do it.

When you git clone, git fetch, git pull, or git push to a remote repository using HTTPS URLs on the command line, Git will ask for your GitHub username and password. When Git prompts you for your password, enter your personal access token. Alternatively, you can use a credential helper like Git Credential Manager. Password-based authentication for Git has been removed in favor of more secure authentication methods. For more information, see "Managing your personal access tokens."

(Emphasis mine.) And when you do see "Managing your personal access tokens", you will find the very clear instructions on how to create your personal access tokens, whether finegrained or classic (all-access) ones.

Third, why default to HTTPS when clearly SSH is more functional

Because that was how you cloned it. (Or, you changed the URL later to be a HTTPS url, though I don't think that is very likely.) If you had cloned it with an SSH URL, you would be doing a push through SSH.

But honestly it seems like my whole team has to do these steps anyhow! And they actually boils down to not that much

If it is not all that much, then it should be easy, right?

Answer 2

I have git config --global url.github:.insteadof https://github.com/ and github configured in ssh, it's that easy, a snip from ~/.ssh/config on my desktop (physically secure so I just keep the sessions up):

AddKeysToAgent yes
ControlMaster auto
ControlPath /run/user/%i/ssh-%C
ControlPersist 86400
IdentitiesOnly yes

host !aur *
    IdentityFile ~/.ssh/id_ed25519

host github github.com
    HostName github.com
    user git
    ControlPersist 300

and from ~/.config/git/config:

[url "github:"]
        insteadOf = https://github.com/
        insteadOf = git://github.com/

Answer 3

How to push with HTTPS

Okay, thank you all for your help. There definitely is a way to push via HTTP:

1. Create a Personal Access Token on the GitHub website via Profile -> settings -> developers setting -> personal access tokens, checking as many of the system access boxes as you like and choosing an appropriate expiration date.
2. Copy the key to clipboard.
3. While cloning down the repo, add the token to the url as git clone https://<username>:<githubtoken>@github.com/<username>/<repositoryname>.git, or if you've already cloned it down, set your upstream url with git remote set-url origin https://<githubtoken>@github.com/<username>/<repositoryname>.git

You can also neglect to have the token in either of the above urls and later, when prompted for username and password, give your standard username and the access token as your password, and the push goes through.

There is also supposedly a way to put the access token in the system keychain instead, but I couldn't quite figure this out. My guess is if configured properly, then the system will prompt you for a fingerprint or system password when the terminal asks for the git password (which again, is actually supposed to be an access token).

This is functionally the same as setting up SSH keys, so the steps are pretty similar.

Design critiques

I still think this is unfortunately complicated.

The fact there are multiple possible protocols here means double the options for users, double the documentation to maintain, potential cross-confusion of instructions, double the code to maintain on the backend. Maybe there really are cases where you want to use one or the other protocol, like from behind a firewall if SSH traffic isn't allowed for some reason, but it violates the design principle that "There should be one-- and preferably only one --obvious way to do it."

Setting up an access token or SSH key requires some computer security know-how. You almost need a UML diagram to picture the systems and responsibilities involved, and you need to know the lore that passwords were discontinued. Somewhere I saw a claim that was because clients might send the password to the server in plaintext, but that seems dubious: All competent clients are supposed to do some hashing before sending passwords to the internet, so no one downstream can see the plaintext. Maybe GitHub wanted to upgrade security from single-factor, and keys achieved that? I would give up some security for convenience here, but I understand forcing users to get with the program so nothing can slip through. But if that's going to be policy, the set-up instructions have to be super clear, and honestly I don't think they are.

The fact is that to get off the ground I have to read through several verbose how-to pages and stackoverflow posts, gathering contextual information piece by piece to understand what I'm doing. Once I have all that together, sure it's easy to write a few commands, but my point is getting there is complicated. The page linked in the error message should have minimum viable steps like above, front and center, with explanation following, no fluff.

The periodic delays this has caused me over the years have been a real headache. It's a turn-off. Each time my eyes glaze over, and I muddle through, frustration hardening into willful ignorance of why any of this should be necessary. Now that I've asked this question and investigated at length, I'll remember, or at least be able to come back for reference. But for the sake of newcomers and other returning oldcomers, it really could be made more intuitive.