GitHub CLI, SSH Keys, Tokens, And Verified Git Identity

Use GitHub's official documentation for current setup details. GitHub documents GitHub CLI, SSH connections, personal access tokens, and Git username configuration. Those docs should be checked before teaching exact screens, token types, scopes, or authentication flows.

Local Git Identity

Git commits store author and committer information. The author usually represents the person who wrote the change. The committer represents the person or tool that committed it. In simple solo work, they are often the same. In rebases, patches, bots, and web edits, they can differ. GitHub displays commits and may associate them with accounts when the email matches a verified address or supported no-reply address.

A learner should configure local Git deliberately:

git config --global user.name "Ada Example"
git config --global user.email "ada@example.com"

These commands are examples, not universal policy. A developer may use a work email for work repositories and a no-reply GitHub email for public personal work. Some organizations require specific email domains or commit signing. The important principle is that the email should be intentional, verified where GitHub attribution matters, and appropriate for privacy.

Do not teach learners to copy another person's Git config from a tutorial. The author name and email become part of commit history. They should represent the real author identity policy for that context.

Authentication Is Not Attribution

Authentication answers are you allowed to perform this operation now? Attribution answers who does this commit say authored the change? You can authenticate successfully and still create commits that GitHub does not attribute to your profile. You can also have correctly attributed commits while a push fails because your credentials are expired or lack permission.

This distinction matters during troubleshooting. If git push fails, inspect remote URL, credential helper, SSH key, token state, organization SSO requirements, and repository permission. If a commit does not show on the contribution graph, inspect author email, verified email settings, branch and repository visibility, and GitHub's contribution rules. Do not change random settings until you know which layer failed.

SSH Keys

SSH keys allow Git clients to authenticate to GitHub without typing a password. A key pair has a private key that stays on your machine and a public key that can be added to GitHub. The private key is sensitive. Anyone who obtains it may be able to authenticate as you unless the key is protected and revoked quickly.

Good SSH practice includes using a modern key type supported by GitHub, protecting the private key with a passphrase where practical, storing it only on trusted machines, removing keys from GitHub when a device is retired or lost, and naming keys clearly so you can identify them later. A label like old laptop becomes useless after two years. A label like Ada MacBook Pro 2026 is easier to audit.

SSH keys are account-level credentials unless scoped through deploy keys or other mechanisms. Do not use a personal SSH key as a production deployment credential for a team application. If a server needs repository access, prefer a deploy key, GitHub App, machine user, or Actions-based workflow with least privilege depending on the situation. The right choice depends on who owns the repository and how the deployment is controlled.

Personal Access Tokens

Personal access tokens are credentials for GitHub API or HTTPS operations. They should be treated like passwords with explicit permissions. GitHub supports token management through current documented flows, including fine-grained tokens in supported contexts. The exact options change, so the stable lesson is least privilege: create a token only for the operation needed, give it the narrowest repository and permission access available, set expiration when possible, store it in an appropriate credential manager or secret store, and revoke it when no longer needed.

Avoid long-lived broad tokens in scripts. A token with access to every repository in an account is a large blast radius. A token pasted into a shell history, README, issue, or CI log is compromised. A token used by several systems becomes hard to rotate because nobody knows which system will break.

For CI/CD, prefer platform features that avoid personal credentials. GitHub Actions provides a workflow token and supports secrets and environments. Deployments to remote servers should use environment protection, narrow credentials, and auditable workflows. If a personal access token is truly necessary, document who owns it, what it can access, when it expires, and how to rotate it.

GitHub CLI

The GitHub CLI, gh, wraps many GitHub operations in terminal commands: authentication, repository creation, issue work, pull request creation, checks, review, releases, and more. It is useful because it keeps a developer in the terminal while still using GitHub platform features. It is not a replacement for understanding Git, permissions, or review policy.

A typical learner workflow is to authenticate with gh auth login, inspect status with gh auth status, create a pull request with gh pr create, check CI with gh pr checks, review with gh pr review, and view issues with gh issue list. These commands should be taught as examples tied to the official manual, not as scripts to paste blindly into every project. Organization SSO, repository permissions, and local credential storage can change behavior.

Aliases can make common commands faster, but they should not hide destructive or policy-sensitive actions. A short alias that lists assigned reviews is harmless. An alias that merges pull requests, deletes branches, or reruns deployments should be reviewed like any other automation.

Verified Email And Privacy

GitHub commit attribution depends in part on email configuration. A learner who wants public contributions associated with a profile should use an email GitHub recognizes for that account or a supported no-reply address. A learner who wants privacy should avoid putting a personal address into public commits. Work repositories may require a company address for legal or audit reasons.

The safest habit is to check identity at repository setup time:

git config user.name
git config user.email
git remote -v

These commands produce visible local configuration and remote information. They do not prove GitHub attribution by themselves, but they catch many mistakes before the first commit.

Troubleshooting Credential Failures

Credential failures should be diagnosed from the outside in. First confirm the operation: clone, fetch, push, API request, package publish, or workflow deployment. Then confirm the transport: SSH or HTTPS. Then confirm the identity: which GitHub account or automation principal is being used. Finally confirm the permission: does that identity have access to the repository, organization, package, environment, or branch?

For SSH, useful checks include the remote URL, loaded keys, GitHub key list, key labels, and whether the organization has additional access requirements. For HTTPS, useful checks include credential-manager state, token expiration, repository selection, and required scopes or permissions. For GitHub CLI, gh auth status can show which account and host the CLI believes it is using. It does not replace checking whether the account has the right repository permission.

Avoid solving every failure by creating a new broad token. That creates credential sprawl and often leaves the original problem unexplained. A safer troubleshooting habit is to identify the minimal failed operation, verify current credentials, remove stale credentials when appropriate, and create a narrow replacement only when the existing credential is truly wrong or expired.

Rotation And Offboarding

Credential setup is not finished until rotation and offboarding are planned. Developers change laptops, leave teams, rotate roles, and lose devices. A healthy GitHub setup can answer which SSH keys belong to which machines, which tokens exist, what each token can access, which automation credentials deploy production, and who can revoke them in an emergency.

Offboarding should remove repository and organization access, revoke or review personal tokens used for work, remove obsolete SSH keys where appropriate, rotate shared secrets, and confirm deployment automation does not depend on the departing person's account. If a production deployment uses a personal credential, offboarding becomes risky because removing access can break releases. That is why team automation should be owned by the organization or deployment platform, not by one developer's laptop.

Credential rotation should be tested like any other operational workflow. If nobody knows how to replace a deployment key without downtime, the team does not really control that credential. Store enough documentation for a trusted maintainer to rotate keys and tokens, but never store the secret values themselves in the documentation.

Review Checklist

A good GitHub credential setup can be reviewed without exposing secrets. Confirm that local Git author name and email are intentional, GitHub email verification matches the attribution goal, SSH keys are named and current, old keys are removed, tokens have narrow access and expiration, gh auth status shows the expected account, and automation does not depend on an unowned personal credential.

The learner should be able to distinguish authentication from commit attribution, choose SSH keys or tokens for the right job, use GitHub CLI without hiding policy decisions, protect private keys and tokens, and verify that their local Git identity matches the profile and repository context they intend.

gh alias set ship 'pr merge --squash --delete-branch && gh workflow run deploy.yml'