المصادقة مع GitHub (مفاتيح SSH أو tokens)

Written Explanation

Authentication is not authorization

Two words are often mixed up. Authentication proves who you are. Authorization decides what that person may do. GitHub first authenticates you (token or key), then checks whether your account may push to that repository. A repository you do not own will reject your push even if you are authenticated perfectly.

Why not a password?

When you clone, fetch, pull, or push over HTTPS to a private repository, Git asks for a username and password. GitHub's documentation states that account passwords are no longer accepted for Git operations; you supply a personal access token (PAT) where the password goes, or use a tool that obtains credentials for you. This protects you: a token can be limited and revoked without changing your account password.

Route 1: HTTPS with a token

A personal access token is a string you create in your GitHub account settings (under Developer settings, then Personal access tokens). GitHub offers two kinds. Fine-grained tokens can be limited to specific repositories and specific permissions; classic tokens use broad scopes and reach every repository you can access. GitHub recommends fine-grained tokens whenever they can do the job, setting an expiry date, and choosing the minimum permissions needed. Treat a token exactly like a password.

You rarely type a token by hand every time. GitHub recommends letting a helper remember credentials: Git Credential Manager (it ships with current Git for Windows) or the GitHub CLI (gh auth login). On the first HTTPS operation that needs authentication, such a tool can open a browser login, and afterwards the credentials are kept in your system's secure store and reused. Where a manual token is needed, you paste it when Git asks for the password. The username is your GitHub username.

Route 2: SSH keys

An SSH key pair is two files made together:

• The private key stays on your computer. It is your proof of identity. Never share it, never copy it into a project, never commit it.
• The public key is a lock that matches it. It is safe to share, and you upload it to GitHub.

When you connect, GitHub challenges your computer to prove it holds the private key matching a public key on your account. The private key itself is never sent. That is why uploading the public half is safe.

To create a pair, GitHub documents the Ed25519 type:

ssh-keygen -t ed25519 -C "you@example.com"

The -C value is only a label (a comment) stored in the public key. Run in a scratch folder with a fixed file name and an empty passphrase (for demonstration only), it printed:

Generating public/private ed25519 key pair.
Your identification has been saved in ./testkey
Your public key has been saved in ./testkey.pub
The key fingerprint is:
SHA256:2LKnZAZduWPYJw7QkS5Jbjml5zNFtoAVhJ9a5GTANnw you@example.com

With default settings, the files are id_ed25519 (private) and id_ed25519.pub (public) in the .ssh folder of your home directory. The .pub ending is your clue: it is the one you upload. When ssh-keygen asks for a passphrase, set one: it encrypts the private key file so a stolen file is not enough. An SSH agent can hold the unlocked key for the session so you do not retype the passphrase on every push; the setup differs by operating system, so follow GitHub's documented steps for yours.

To register the key, copy the full text of the .pub file and paste it into your account settings under SSH and GPG keys, using New SSH key, a descriptive title such as "Home laptop", and the key type "authentication". Then test:

ssh -T git@github.com

On the very first connection, SSH may ask you to confirm the server's fingerprint; GitHub tells you to compare it with the fingerprints GitHub publishes, and only then type yes. On success the message says you have successfully authenticated but that GitHub does not provide shell access. The command then exits with a non-zero code: that is normal, because GitHub intentionally offers no shell.

Finally, point your remote at the SSH URL (the git@github.com:you/repo.git form):

git remote set-url origin git@github.com:you/bank-accounts.git
git remote -v

Which route should you choose?

Neither is "more correct". Either is fine for this course.

Secrets do not belong in the repository

Tokens, private keys, passwords, and API keys must never be committed. A repository's history is permanent and everyone who clones gets all of it. Deleting the file in a later commit does not remove it from earlier ones. GitHub scans public repositories for known kinds of secrets, and its advice if one leaks is to revoke or rotate the credential immediately: once revoked, it is worthless, and rewriting history becomes much less urgent. In the previous module you wrote a .gitignore that excludes secrets; that is your first line of defense. Keep tokens and keys in your credential manager, ~/.ssh, or an environment variable, outside any project folder.