Alex: Welcome back. Today we're talking about Git authentication, which is the part of GitHub that proves you are who you say you are before GitHub lets you change something.

Jamie: So this is the moment where Git stops being just, I can read this project, and becomes, I am allowed to push changes here.

Alex: Exactly. GitHub asks you to authenticate when you push commits, clone a private repository, or access organization repositories that require certain permissions. You usually do not need authentication to clone a public repository, view public code on GitHub.com, or read public issues and pull requests.

Jamie: And if somebody is only using the GitHub website or GitHub Desktop, they may not have to touch this appendix right away.

Alex: Right. This becomes most relevant when you're using VS Code with command-line Git and you want to push commits to your fork or another repository. The reference is set up with two main paths, a Personal Access Token path and an SSH key path, plus troubleshooting by exact error message. If you use a screen reader, heading navigation and numbered steps are useful here; if you use magnification, the code blocks and separate method sections help you keep the two paths apart.

Jamie: Okay, two paths. Is that the same as HTTPS versus SSH?

Alex: Yes. With HTTPS, your remote URL usually starts with https://github.com, and Git asks for a username and a credential. With SSH, your remote URL usually looks like git@github.com:owner/repo.git, and Git proves your identity with a key stored on your computer.

Jamie: The HTTPS credential is the Personal Access Token, right? Not my GitHub password.

Alex: Correct. A Personal Access Token, or PAT, is a password-like string you generate on GitHub and paste when Git asks for a password. GitHub has fine-grained tokens, which can be limited to specific repositories and permissions, and classic tokens, which are broader and still appear in many workshop instructions. The workshop reference recommends a classic token because it is straightforward to create through the web interface, but the security habit is the same either way: grant only the access you need.

Jamie: The nice part is that tokens work everywhere and are easy to revoke. The less nice part is that you have to store them safely, and they expire.

Alex: That's the tradeoff. SSH uses a key pair instead: a public key that you add to GitHub, and a private key that stays on your computer. Once SSH is set up, it usually stops prompting you, but the first setup is more command-line heavy. And the private key is secret; never paste it into GitHub, email, chat, or a repository.

Jamie: If I'm following the recommended workshop route, how do I make the token?

Alex: Start at github.com/settings/tokens. Choose Tokens classic, then generate a new classic token. Give it a clear note, such as Workshop Laptop Token, choose a short expiration like 30 or 60 days, and select the scopes you need. The common workshop scope is repo, and workflow is only needed if you will update GitHub Actions workflow files.

Jamie: And when GitHub shows the token, copy it right then. You don't get to come back and view it later.

Alex: Yes. If you're using a screen reader, the token appears as a long string in a text field, so select all, copy, and move it directly into a safe place. A password manager is best, an encrypted note can work, and a plain text file should only be temporary and only inside an encrypted folder.

Jamie: What should people avoid?

Alex: Do not paste the token into an unencrypted document that syncs to the cloud. Do not email it to yourself. And definitely do not save it in a public GitHub file. The next time Git asks for credentials, enter your GitHub username, and paste the token where Git asks for a password.

Jamie: This is where credential storage helps, because nobody wants to paste that long token every time.

Alex: Exactly. Git Credential Manager is the recommended cross-platform helper because it stores credentials securely and integrates with GitHub sign-in flows. On Windows, Git Credential Manager often remembers the token after first use. On macOS, Keychain may ask to save it, and you can choose Always Allow. On Linux, you can use Git Credential Manager too, or a temporary cache with git config --global credential.helper cache.

Jamie: What about the SSH path? I know people like it, but the words public key and private key can sound a little mysterious.

Alex: Start by checking whether you already have one. In a terminal, run ls -al ~/.ssh and look for files like id_rsa.pub or id_ed25519.pub. The .pub file is the public key, and the matching file without .pub is the private key.

Jamie: If there is no key, the command is ssh-keygen, right?

Alex: Yes. A common modern command is ssh-keygen -t ed25519 -C "your-email@example.com". When it asks where to save the key, pressing Enter accepts the default location. A passphrase is optional, but recommended, because it protects the key if someone gets access to your computer.

Jamie: Then we copy the public key, not the private one.

Alex: Exactly. In Windows PowerShell, you can use Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard. On macOS, use pbcopy < ~/.ssh/id_ed25519.pub. On Linux, you can run cat ~/.ssh/id_ed25519.pub, then manually select and copy the output.

Jamie: And that output should start with something like ssh-ed25519 or ssh-rsa.

Alex: Right. Then go to github.com/settings/keys, choose New SSH key, give it a title like Workshop Laptop SSH Key, set the key type to Authentication Key, paste the public key, and add it. GitHub may ask for your password or 2FA code. After that, test with ssh -T git@github.com, and a successful response starts with Hi username, you've successfully authenticated.

Jamie: Here's a very real question. What if I set up SSH perfectly, but my repository was cloned with HTTPS?

Alex: Then Git will still try to use the HTTPS route, because the remote URL controls the method. Run git remote -v to see the current remote. If you want SSH, set it with git remote set-url origin git@github.com:your-username/repo.git.

Jamie: And to go the other direction?

Alex: Use git remote set-url origin https://github.com/your-username/repo.git. This is worth checking before you regenerate tokens or keys, because the wrong remote URL can make a working credential look broken. HTTPS expects a token or credential helper, and SSH expects a configured key.

Jamie: Authentication errors can feel personal, but they usually have pretty specific causes.

Alex: They do. If you see Authentication failed when pushing, the token is often expired, mistyped, or stored incorrectly. Generate a new PAT, clear the old saved credential from Windows Credential Manager, macOS Keychain, or on Linux with git credential-cache exit, and push again so Git asks for credentials.

Jamie: What about Permission denied publickey?

Alex: That means SSH did not find a key GitHub accepts. Check that the public key is added at github.com/settings/keys, then run ssh-add -l to see what your SSH agent knows about. If your key is missing, add it with ssh-add ~/.ssh/id_ed25519.

Jamie: And Host key verification failed?

Alex: That means your computer does not recognize GitHub's host key yet, or the stored host key does not match. The reference gives ssh-keyscan github.com >> ~/.ssh/known_hosts as the direct fix. If anything about the warning seems unusual, pause and verify against GitHub's official SSH documentation before accepting a host key.

Jamie: Let's talk security habits, because tokens and keys are powerful.

Alex: Treat a PAT and a private key like passwords. Use the smallest token scopes that will do the job, set expiration dates on tokens, use a passphrase on SSH keys, and revoke old tokens when you're done with a project or device. Also, do not commit tokens, private keys, or local config files that contain secrets; use .gitignore for files that should stay on your machine.

Jamie: But the public key is different.

Alex: Yes. The public key is meant to be uploaded to GitHub and can be shared in that limited sense. The private key and tokens are the pieces that must stay protected.

Jamie: Commit signing sounds related, but it is not exactly the same as logging in, is it?

Alex: Right. Authentication lets you push or access a repository. Commit signing marks individual commits with a cryptographic signature, and GitHub can show a Verified badge when the signature matches a key connected to your account.

Jamie: So maintainers can see that the commit really came from a trusted key, not just from a name and email typed into Git config.

Alex: Exactly. There are two common signing methods. SSH signing is simpler for many learners because it can reuse an SSH key you already have, though you still add it to GitHub as a signing key and configure Git for SSH signing. GPG signing is the older traditional method and has more setup steps.

Jamie: Give me the short version of SSH signing first.

Alex: You tell Git to use SSH for signing with git config --global gpg.format ssh. Then you set your signing key, usually pointing Git at your public SSH key file, and turn on signing with git config --global commit.gpgsign true. In GitHub settings, add the same public key as a signing key, not just an authentication key.

Jamie: And the GPG route is the one with key IDs and the public key block.

Alex: Yes. You generate a GPG key with gpg --full-generate-key, choose RSA and RSA, 4096 bits, and usually no expiration if that is what your organization expects. Use the email address associated with your GitHub account. Then find the key ID with gpg --list-secret-keys --keyid-format=long; the output includes something like sec rsa4096/XXXXXXXXXXXXXXXX, and the X part is the key ID.

Jamie: Then export the public part and add it to GitHub.

Alex: Right. Export it with gpg --armor --export followed by the key ID, and copy the block that starts with BEGIN PGP PUBLIC KEY BLOCK. Add that public key in GitHub's SSH and GPG keys settings. Then configure Git with your signing key ID and turn on commit.gpgsign true so future commits are signed automatically.

Jamie: Where does Vigilant Mode fit into this?

Alex: Vigilant Mode is a GitHub account setting that makes commit verification more visible and stricter in how unsigned or unverified commits are shown. Some maintainers use it because they want a clearer signal about which commits were signed by trusted keys. As a contributor, you may see badges such as Verified, Unverified, or Partially verified beside commits.

Jamie: If you're using a screen reader, don't just assume the icon color tells the whole story.

Alex: Right. Move to the badge text near the commit, and open the badge details when you need the reason. GitHub will usually explain whether the signature is valid, missing, attached to an unknown key, or tied to an email mismatch.

Jamie: For this workshop, the practical recommendation is still pretty calm.

Alex: Use a Personal Access Token if you need a straightforward way to push from the command line. Use SSH if you're comfortable with terminal setup and want a smoother long-term flow. Commit signing is valuable, especially in security-conscious projects, but it is usually something to add after your basic push workflow is working unless a repository specifically requires it.

Jamie: So the pattern is: choose HTTPS with a token or SSH with a key, store secrets safely, check your remote URL, and troubleshoot from the exact error message.

Alex: Exactly. Authentication is GitHub checking whether the person asking to change a repository is allowed to do it. Once that is set up, push, pull, and contribution work get much quieter.