CHAPTER 12

Authentication

Ishaan's password is correct. GitHub rejects it anyway. Vidha's seen this exact confusion a dozen times running the beginner track.

Wednesday, the beginner track's weekly meetup

Ishaan tries to push his fixed-typo branch and gets a wall of red text ending in remote: Support for password authentication was removed. He's typed his GitHub password correctly — he just watched himself do it. Vidha, running her beginner Git-track session this week, doesn't even look up. "Yeah, that's everyone's first push. GitHub stopped accepting account passwords for this back in 2021 — too many people's passwords were getting leaked from other unrelated websites and then tried against GitHub automatically. A password typed into a terminal, once, can be logged or guessed in ways a properly scoped credential can't. You need one of three actual login methods for command-line Git specifically."

Path 1: the GitHub CLI — what Vidha has everyone use first

She has Ishaan install GitHub CLI, then run one command:

gh auth login
$ gh auth login
? What account do you want to log into? GitHub.com
? Preferred protocol: HTTPS
? How would you like to authenticate? Login with a web browser
! First copy your one-time code: A1B2-C3D4
Press Enter to open github.com in your browser...

He pastes the code into the browser tab that opens, confirms, and that's it — gh quietly handles a proper access token behind the scenes from then on, refreshing it automatically. Every plain git push and git pull from this terminal now just works, no further prompts.

Path 2: SSH keys — what Vidha actually uses day to day

"The CLI's the easy on-ramp," she says, "but once you're doing this daily, an SSH key is one less thing to think about ever again." She generates a fresh pair on her own laptop to demonstrate:

a new key pair
$ ssh-keygen -t ed25519 -C "vidha@example.com"
Enter file: [Enter for default ~/.ssh/id_ed25519]
Enter passphrase: [a real one — this unlocks the key locally]

"Two files come out of that," she explains. "One private, one public. The private one" — she points at id_ed25519, no extension — "never leaves your machine, ever, to anyone, including me. This one" — id_ed25519.pub — "is safe to hand to GitHub. It can only be used to check that you hold the private half, not to impersonate you."

only the public half travels
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... vidha@example.com

That string gets pasted at github.com/settings/ssh/new, named something identifiable like "Vidha's laptop." From then on, any repo cloned with an SSH-style URL (git@github.com:... instead of https://github.com/...) authenticates silently, every time, no token to type or refresh.

proving it worked
$ ssh -T git@github.com
Hi Vidhaaaaaa! You've successfully authenticated.

Path 3: HTTPS with a Personal Access Token — for locked-down networks

"Some hostel or campus networks block the port SSH needs," Vidha adds. "If that ever happens to you, HTTPS still gets through — you just need a token instead of your account password." At github.com/settings/tokens: generate a token, set it to expire (90 days is a sane default — a token that never expires is a bigger loss if it ever leaks), tick the scopes actually needed (repo covers most day-to-day work), copy it once — GitHub shows it exactly once, ever.

not typing it every single time
$ git config --global credential.helper store
# macOS: use the system Keychain instead of a plain-text file
$ git config --global credential.helper osxkeychain

The token gets pasted once, in place of a password, the next time Git asks. It's remembered from then on.

Not leaving your real email exposed

Ishaan asks a fair follow-up: does his real email now show up on every public commit? Only if he set it that way back in Chapter 2. GitHub gives every account a private relay address under Settings → Emails → "Keep my email addresses private" — something like 12345+ishaan@users.noreply.github.com. Set that as user.email instead, and commits still count as his on GitHub without exposing the real address to the public.

Signed commits — proving the name on the commit is really you

One more layer, worth knowing exists even before it's strictly needed: anyone can set user.name to any string at all — nothing stops someone from committing as "Vidha" without being Vidha. Signed commits close that gap using cryptography rather than a trust-me field:

reusing the SSH key you already made
$ git config --global gpg.format ssh
$ git config --global user.signingkey ~/.ssh/id_ed25519.pub
$ git config --global commit.gpgsign true

Add the same public key a second time on GitHub, this time as a "Signing key" rather than an "Authentication key," and every future commit carries a green Verified badge — cryptographic proof, not just a name field, that the commit really came from the account it claims to. Accelerate treats this as recommended rather than mandatory day-to-day, but expects it on anything constitutional: governance edits, meeting minutes, transparency reports.

CHECK
Ishaan is on the campus network, which blocks the port SSH needs. What's his fallback?
HTTPS traffic almost always gets through where SSH's port might be blocked. A Personal Access Token is the credential HTTPS-based Git authentication actually accepts now — the old account-password method was removed in 2021 for everyone, everywhere, regardless of network.

Ishaan's authenticated now. He pushes his branch to his fork successfully for the first time, and it's time to actually open the pull request — the part where his fix stops being his own private branch and becomes something the rest of the club can see, discuss, and decide on.