GitHub Account Setup: Security, Identity and Authentication

Your GitHub account is an identity that other people’s security depends on. If it is compromised, the attacker does not just get your code — they get the ability to push to every repository you can write to, and to publish releases that other people install.

That is the reason to spend twenty minutes on setup rather than two. Most of this lesson is about authentication, and the parts that look like administrative trivia — email privacy, recovery codes, which name goes in a commit — are the parts that are annoying to fix later.

Before you start

• Git installed locally (Ubuntu, Windows, macOS)
• Comfort with a terminal

The two identities you are about to create

This trips up nearly everyone once, so it is worth stating before anything else.

Your Git identity is two strings in a config file: user.name and user.email. Git stamps them onto every commit you make. Git does not verify them. You can set them to anything.

Your GitHub identity is an account with a username, a password, and credentials that prove you control it.

They are connected by exactly one thing: when GitHub displays a commit, it looks at the commit’s author email and tries to match it to an account. If it matches, you get the avatar and the profile link. If it does not, the commit still exists and still belongs to the repository — it is just attributed to a name rather than to a user.

Why your commits sometimes are not "yours"

A commit authored with an email GitHub cannot match will not appear on your contribution graph and will not link to your profile. Nothing is broken and nothing needs rewriting; the email simply is not one GitHub associates with your account. Adding that address to your account retroactively fixes the attribution, because the match is computed at display time.

The practical consequence: anyone can author a commit claiming to be you. Git’s author field is not authentication. If that matters for your project — and for anything published or deployed it usually does — the answer is signed commits, which add cryptographic proof that Git’s metadata cannot provide.

Choosing a username

Your username becomes part of every repository URL you own, your profile URL, and your github.com/<name> identity across the ecosystem. It is changeable, but changing it breaks links that other people control.

Some things worth weighing:

• It is public and permanent-ish. Treat it as a professional handle rather than a joke you will have to explain in interviews.
• Short is genuinely better. You will type it into remote URLs and CLI commands constantly.
• Avoid encoding your current employer or project. Both change; the account outlives them.
• Personal account, not shared. If several people need access to the same repositories, that is what an organisation is for. Shared accounts cannot be audited, cannot have per-person 2FA, and cannot have access revoked for one person.

Email addresses and privacy

GitHub separates the address you sign in with from the address that appears in commits, and understanding the split saves trouble later.

By default GitHub can provide a noreply address of the form ID+username@users.noreply.github.com. When you enable the setting that keeps your email private and use that address as your Git user.email, your commits are still attributed to your account — because GitHub knows the address belongs to you — without publishing a real inbox.

This matters more than it sounds. Commits are permanent and public in public repositories. Every commit you have ever pushed carries the author email in plain text, and scraping those is trivial.

Availability

Email privacy settings, the exact noreply address format and the option to block pushes that expose your address are account settings GitHub controls and occasionally changes. Confirm the current position in the commit email address documentation.

Whichever address you choose, set it locally:

git config --global user.name "Your Name"
git config --global user.email "ID+username@users.noreply.github.com"

What it doesSets the name and email Git stamps on your commits, for every repository on this machine.

Why we run itCommits made before this is set carry whatever Git guessed from your system, which is usually wrong and occasionally embarrassing.

Expected resultNo output. Both commands are silent on success.

Verify what Git will actually use — including which config file it came from, which is invaluable when a repository unexpectedly commits as the wrong person:

git config --show-origin --get user.email

Output:

file:/home/you/.gitconfig  ID+username@users.noreply.github.com

If you contribute under different identities — work and personal, say — do not solve it by editing this value back and forth. Use conditional includes, which switch identity based on the directory you are working in and remove the possibility of forgetting.

Securing the account

This is the part that actually matters.

Two-factor authentication

GitHub currently supports several second factors, and they are not equivalent:

Method	Strength	Notes
Passkeys	Strongest	Satisfy password and 2FA in one step; phishing-resistant
Security keys (WebAuthn)	Very strong	Phishing-resistant, but count only as a second factor
TOTP app	Strong	Works offline; vulnerable to real-time phishing
GitHub Mobile	Strong	Push approval on a device you already carry
SMS	Weakest	Vulnerable to SIM-swapping; availability varies by country

Two distinctions are worth being precise about, because most write-ups blur them.

Passkeys are not the same as security keys. A passkey replaces both the password and the second factor — you sign in with it alone. A security key verifies presence only, so it remains a second factor used alongside your password. Confusingly, the same physical device can often serve as either, and platform authenticators such as Windows Hello, Face ID or Touch ID can be registered as passkeys.

Phishing resistance is the real differentiator. TOTP codes can be relayed by an attacker in real time: you type the code into a convincing fake page, and they use it within the 30-second window. WebAuthn credentials — passkeys and security keys — are bound to the site’s origin, so a fake domain cannot use them at all. If you only change one thing after reading this lesson, make it this one.

2FA is not optional for many accounts

GitHub has required two-factor authentication for accounts that contribute code on GitHub.com, rolled out in waves with an enrolment window rather than all at once. If you are contributing code, assume you will need it, and enable it on your own schedule rather than during a deadline.

Recovery, before you need it

Enabling 2FA without securing recovery is how people lock themselves out permanently. GitHub is not able to simply restore access to an account it cannot verify you own — that limitation is the point of the system.

When you enable 2FA you are given recovery codes. Download them and store them somewhere that survives losing your laptop and your phone at the same time: a password manager that syncs, or printed and physically stored. Do not keep them only on the device that holds your TOTP app.

Register a second factor as well as your first — a second security key, or GitHub Mobile alongside a TOTP app. One device failure should not be an account loss.

The failure mode is total

Losing your only second factor and your recovery codes can mean losing the account, including repositories only you can administer, packages published under your name, and any organisation where you are the sole owner. Set up recovery at the same time as 2FA, not later.

The security checklist

Before moving on, confirm all of the following:

• 2FA enabled, ideally with a passkey or security key
• A second factor registered as a backup
• Recovery codes downloaded and stored outside your primary device
• Commit email privacy configured deliberately
• Sessions and authorised applications reviewed — revoke what you no longer recognise
• Personal access tokens reviewed; delete any you cannot account for
• Email address verified, so account recovery mail actually reaches you

Connecting local Git to GitHub

Authenticating your account in a browser is separate from authenticating the Git client that pushes to it. You have two mainstream options.

SSH

You generate a key pair, keep the private half on your machine, and register the public half with your account. Git then authenticates by proving it holds the private key.

ssh-keygen -t ed25519 -C "your-label@machine"
cat ~/.ssh/id_ed25519.pub

What it doesGenerates an Ed25519 key pair and prints the public half for you to add to GitHub.

Why we run itEd25519 is the current default recommendation: short, fast, and well supported. The comment makes the key identifiable in a list of several.

Expected resultA prompt for a file location and a passphrase, then a key fingerprint and randomart image.

Use a passphrase. An unprotected private key is a credential lying in a file: anyone who reads your disk gets push access to everything. An agent will hold the decrypted key for your session so you type the passphrase once, not once per push.

After adding the public key to your account, verify:

ssh -T git@github.com

Output:

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

That message is a success, despite reading like a refusal.

HTTPS

Git authenticates over HTTPS using a token, not your account password — password authentication for Git operations is no longer accepted. In practice you should not be typing tokens at all: a credential manager stores them in your operating system’s keychain and supplies them automatically.

The simplest path is to let the GitHub CLI configure it, which handles both the token and the Git credential helper:

gh auth login

gh auth covers this command properly, including multiple accounts and non-interactive use in CI.

Choosing between them

	SSH	HTTPS
Credential	Key pair you generate	Token issued by GitHub
Works through restrictive firewalls	Sometimes blocked on port 22	Usually fine
Per-repository scoping	No — the key is account-wide	Yes, with fine-grained tokens
Revocation	Delete the key	Delete or expire the token
Best for	A machine you control long-term	CI, containers, scoped automation

Neither is more secure in the abstract; they fail differently. An SSH key does not expire, which is convenient and also means a forgotten key on an old laptop stays valid until you notice. A token can be scoped to one repository and expire on its own, which is exactly what you want for automation and mildly irritating for daily work.

Verifying your setup end to end

Once everything is configured, confirm it works rather than assuming. Four checks:

gh auth status

Output:

github.com
  ✓ Logged in to github.com account username (keyring)
  - Active account: true
  - Git operations protocol: ssh
  - Token scopes: 'gist', 'read:org', 'repo', 'workflow'

Then confirm Git will commit as the right person, that SSH authenticates, and that a push actually works — the last one being the only test that exercises the whole chain:

git config --get user.email
ssh -T git@github.com

The full end-to-end test is creating a throwaway repository, pushing a commit to it, and checking that the commit is attributed to your account on the web page. If the commit appears but is not linked to your profile, your Git email is not one your account recognises — which is a five-second fix now and a confusing mystery in six months.

Notifications, briefly

GitHub’s default notification volume is high enough that many people stop reading notifications entirely, which is worse than any specific setting. Two adjustments are worth making early:

• Decide whether repository activity reaches you by email, in the web inbox, or both. Choosing one primary channel makes the signal usable.
• Understand that watching a repository subscribes you to its activity, while starring does not. Starring a hundred repositories is harmless; watching a hundred is not.

The Stars lesson covers that distinction and why the two are constantly confused.

Common mistakes

Using a personal account as a team account. It cannot be audited, access cannot be revoked per person, and it becomes a single point of failure when someone leaves.

Enabling 2FA without storing recovery codes. The most common cause of permanent account loss.

Committing with an unrecognised email for months. Everything works; nothing is attributed. Add the address to your account and attribution is corrected retroactively.

Generating an SSH key with no passphrase for convenience. It is convenient for an attacker with filesystem access too.

Keeping tokens you no longer recognise. Every unused credential is an unmonitored way in. Review and delete them periodically.

Assuming the author field proves authorship. It does not, and cannot. That is what commit signing is for.

What you learned

• Your Git identity and your GitHub identity are separate, connected only by email matching at display time — and the author field is metadata, not authentication.
• Commit email privacy exists because commit metadata is permanent and public.
• Passkeys, security keys, TOTP, GitHub Mobile and SMS are not equivalent, and WebAuthn-based methods are meaningfully better because they are phishing-resistant.
• Recovery must be configured at the same time as 2FA, because the failure mode is losing the account.
• SSH and HTTPS are both fine, with different revocation and scoping properties.

Related lessons

Creating GitHub RepositoriesNext: create repositories deliberately rather than accepting defaults.

Signed CommitsCryptographic proof of authorship, which Git's author field cannot provide.

Git Credential ManagersWhere tokens should live instead of in your shell history.

gh authAuthenticating the CLI, multiple accounts, and tokens in automation.