Authenticating with SSH Keys or HTTPS

Your first git push asked for a username and password. GitHub needs proof that the person pushing to maya-okafor/portfolio is Maya. It won’t accept your account password for that; it hasn’t since 2021, when it switched Git operations to stronger credentials. You have two good options, and you only set either one up once per computer.

The two protocols

The remote URL decides how Git talks to GitHub:

https://github.com/maya-okafor/portfolio.git    HTTPS
git@github.com:maya-okafor/portfolio.git        SSH

HTTPS authenticates with a token. A credential manager gets one by sending you through GitHub’s normal browser sign-in (including two-factor) and stores it in your system’s secure storage. SSH authenticates with a key pair you generate; GitHub stores the public half and checks you hold the private half.

Which should you pick? HTTPS with a credential manager is the easiest to set up and works on any network that allows web browsing. SSH takes five more minutes, doesn’t expire (GitHub only removes a key after a year without use), and is what many developers use day to day. Both are equally secure when set up properly. If in doubt, start with HTTPS; you can switch any time.

Option 1: HTTPS with a credential manager

Git Credential Manager (GCM) comes with Git for Windows. On macOS, install it with Homebrew (brew install --cask git-credential-manager); on Linux, follow the install guide on its GitHub page. The next time Git needs credentials, a browser window opens, you sign in to GitHub and approve, and GCM stores the token. You won’t be asked again.

If you’ve installed the GitHub CLI, it can do the same job:

gh auth login

Choose GitHub.com, HTTPS, and answer yes to “Authenticate Git with your GitHub credentials?”. It signs you in through the browser and configures Git to use it as a credential helper.

The manual alternative is a personal access token: create one under Settings, Developer settings, and paste it where Git asks for a password. It works, but you have to manage expiry and storage yourself, so prefer a credential manager on your own machine and keep tokens for automation.

Option 2: SSH keys

Generate a key pair. Ed25519 is the modern default:

ssh-keygen -t ed25519 -C "maya.okafor@example.com"

Press Enter to accept the default location, then set a passphrase. The passphrase protects the private key if your laptop is ever stolen. The comment after -C is a label to help you recognise the key later.

You now have two files:

• ~/.ssh/id_ed25519, the private key. It never leaves this machine.
• ~/.ssh/id_ed25519.pub, the public key. Safe to share; this is what GitHub gets.

Load the key into the SSH agent so you type the passphrase once per session, not on every push:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 stores the passphrase in your Keychain; GitHub’s guide shows the matching ~/.ssh/config lines. Then copy the public key (pbcopy < ~/.ssh/id_ed25519.pub on macOS, or open the file and copy its single line), and on GitHub go to Settings, SSH and GPG keys, New SSH key, and paste it.

Test the connection:

ssh -T git@github.com

The first time, SSH asks you to confirm GitHub’s host fingerprint; compare it with the fingerprints GitHub publishes in its docs before typing yes. Success looks like this:

Hi maya-okafor! You've successfully authenticated, but GitHub does not provide shell access.

That “does not provide shell access” line is normal; you’re not logging in to a server, only proving who you are.

Pointing the remote at the right protocol

Authentication follows the URL. If you set up SSH but cloned with HTTPS, Git keeps using HTTPS. Check and switch:

git remote -v
git remote set-url origin git@github.com:maya-okafor/portfolio.git
git push

Going the other way is the same command with the https:// URL.

With pushing sorted, you can start working the way teams do on GitHub: through pull requests.