In the previous article, we saw that when connecting our repository to the cloud, we had two paths: use HTTPS or configure SSH.
We already said that SSH is the recommended option. It’s more secure and, furthermore, much more convenient in the long run because it frees us from constantly managing tokens and passwords.
Configuring SSH requires investing five minutes for a small setup between your computer and GitHub. But in return, Git will never ask you for a password again.
How does it work?
The SSH protocol uses Asymmetric Cryptography. That is, instead of a password, we are going to generate two mathematically linked files:
- Private Key (
id_ed25519): It’s YOUR KEY. It’s stored on your computer. NEVER share it. - Public Key (
id_ed25519.pub): It’s THE LOCK. You can give it to anyone (in this case, to GitHub).
When you try to connect to GitHub, the server checks if the key in your pocket (Private) fits the lock you gave it some time ago (Public). If it fits, it lets you in without asking anything else.
Today we are going to set up your computer to connect with Git without passwords, more securely, and also more conveniently. Let’s get started. 👇
Step 1: Generate the key pair
We are going to use the ed25519 algorithm. It’s the modern standard: it’s faster and generates shorter, more secure keys than the old RSA.
Run the following command (replacing the email with yours, oooobviously):
ssh-keygen -t ed25519 -C "[email protected]"
The terminal will ask you a few questions. You can press Enter on all of them to accept the default values:
File in which to save the key: Press Enter (it will save it in ~/.ssh/id_ed25519).
Enter passphrase:
- If you leave this empty (Enter), Git will never ask for a password. It’s the most convenient.
- If you type a passphrase, you’ll have an extra layer of security (if your laptop is stolen, they won’t be able to use your key without the phrase), but you’ll have to type it every time (or configure an agent).
When finished, you’ll see a piece of “random art” in the console. You have created your keys.
For this course, I recommend leaving the passphrase empty, or using a simple one.
Step 2: Copy the public key
Now we need to take the public key (the lock) to give it to GitHub.
I repeat: Make sure to copy the file that ends in .pub. Never share the file without an extension.
You can display the content in the terminal and copy it with the mouse:
cat ~/.ssh/id_ed25519.pub
The content will be a long line starting with ssh-ed25519 AAAA... and ending with your email. Copy everything.
Step 3: Add the key to GitHub / GitLab
Now we are going to tell the server “This is my lock”.
Go to github.com and log into your account.
Click on your profile picture (top right) Settings.
In the left sidebar, look for SSH and GPG keys.
Click the green New SSH key button.
Title: Give it a name to identify your computer (e.g., “Luis’s Laptop”, “Home PC”).
Key type: Leave it as “Authentication Key”.
Key: Paste the content you copied in the previous step.
Click Add SSH key.
Go to your user preferences.
In the sidebar menu, look for SSH Keys.
Paste your key in the “Key” text box.
The title will be filled in automatically.
Click Add key.
Test the connection
Now let’s check that everything works correctly. Let’s go to the terminal and try to connect to GitHub via SSH.
ssh -T [email protected]
If you use GitLab, it would be ssh -T [email protected]
The first time you connect, you will see a message like this:
The authenticity of host ‘github.com’ can’t be established… Are you sure you want to continue connecting (yes/no/[fingerprint])?
This is normal. Your computer is saying: “I don’t know this server, do you trust it?”. Type yes and press Enter. If everything went well, you will see a success message:
Hi YourUsername! You’ve successfully authenticated, but GitHub does not provide shell access.
Congratulations! You are now securely connected.
Multiple keys
Almost all tutorials will tell you to accept the default name (id_ed25519). To start, it’s fine, but in the real world it’s a security hole.
If you use the same key for your personal GitHub, work GitHub, and your servers, and that key is stolen, they have access to all your apps. The correct practice is to use a different key for each environment (one personal, another for work, etc).
Generate keys with specific names
Instead of accepting the default name, let’s tell Git exactly what we want each file to be called using the -f parameter.
# For your personal account
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github_personal
# For your work account
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github_work
The configuration file (config)
Now you have several keys in your ~/.ssh folder, but your computer doesn’t know which one to use when you try to connect to GitHub.
To explain it, we must create (or edit) a file called config in that same folder. Inside, we are going to create “aliases” (made-up names) for each of your identities:
# --- PERSONAL GITHUB ---
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/github_personal
IdentitiesOnly yes
# --- WORK GITHUB ---
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/github_work
IdentitiesOnly yes
The IdentitiesOnly yes parameter is crucial. It tells your SSH client not to try wildly all the keys you have in the folder, but exclusively the one you are indicating in that block.
Use your aliases when cloning
From now on, when you go to work with a repository, don’t use the standard URL that GitHub gives you ([email protected]:user/repo.git).
Simply change the github.com part for the alias you invented in the previous step. For example, to download a project from your personal account:
git clone git@github-personal:your_user/your_repo.git
Your computer finds the text github-personal, will go read the config file, understand that the real server address is github.com and will authenticate using only the key ~/.ssh/github_personal
