
SSH keys replace your password with a cryptographic key pair. The private key never leaves your machine. The public key goes on the server or in GitHub. When you connect, both keys are checked against each other and you are in, no password required. This tutorial takes you from zero to a working setup with one key for GitHub and one for a remote server, managed by a single config file that handles everything automatically. You will need a terminal, about 30 minutes, and a GitHub account.

Time needed
About 30 minutes
Cost
Free
Difficulty
Beginner, no prior SSH experience needed
What you get
Passwordless login to GitHub and one remote server
There are two key types you will see everywhere: RSA and Ed25519. RSA is the older standard; it is supported by everything but slow to generate and produces long keys. Ed25519 is an elliptic curve algorithm: shorter keys, faster signatures, identical or better security. GitHub, GitLab, Bitbucket and every modern Linux server support it. Unless you are connecting to a legacy system running OpenSSH below version 6.5 (released 2014), use Ed25519.
Run this command on your local machine. The comment after -C is just a label to identify the key later: your email address is conventional, but any string works.
ssh-keygen -t ed25519 -C "your@email.com"
Accept the default file path when prompted. This creates two files: the \
private key at ~/.ssh/id_ed25519 and the public key at \
~/.ssh/id_ed25519.pub. When asked for a passphrase, choose a strong one. \
You will only have to type it once per session if you follow step 5.Never share the file id_ed25519. That is your private key. The file you share is id_ed25519.pub, the one with .pub at the end. The private key stays on your machine only.
If you have a remote server you SSH into with a password, copy the public key there now. The ssh-copy-id command handles the file placement and permissions in one step.
ssh-copy-id user@your-server-ip
Type your password one final time. The command appends your public key to \
~/.ssh/authorized_keys on the server with the correct permissions. \
After this, you can log in without a password.
If ssh-copy-id is not available (on some minimal systems), use the manual \
command below. It does exactly the same thing.cat ~/.ssh/id_ed25519.pub | ssh user@your-server-ip \
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Test it immediately:ssh user@your-server-ip
If the key is accepted you land at the prompt with no password prompt.GitHub uses your public key to verify pushes and pulls over SSH. Print your public key, then copy the entire output.
cat ~/.ssh/id_ed25519.pub
Go to github.com, click your avatar, then Settings, then SSH and GPG \
keys. Click New SSH key, give it a name (like "Work MacBook"), paste the \
key and save. Test the connection from your terminal.ssh -T git@github.com
A successful response looks like: Hi username! You have successfully \
authenticated, but GitHub does not provide shell access.This is the piece that makes everything click. Without a config file, you type the full username, hostname and port every time. With one, you type ssh work or git push and it handles everything. Create or open the config file in your editor. It has no extension.
mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/config
Paste this template, adjusting the values for your setup. Each Host block \
is a named shortcut.# GitHub
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
AddKeysToAgent yes
# Personal VPS or home server
Host myserver
HostName 203.0.113.5
User ubuntu
Port 22
IdentityFile ~/.ssh/id_ed25519
# Work server (if you use a separate key for work)
Host work
HostName work.example.com
User deploy
Port 2222
IdentityFile ~/.ssh/id_ed25519_work
Set the permissions on the config file:chmod 600 ~/.ssh/config
Now ssh myserver connects to 203.0.113.5 as ubuntu with your key. \
Git operations against github.com use the GitHub block automatically.On macOS, the ssh-agent can store your key passphrase in the system Keychain so you only type it once after a reboot, never again mid-session. Add these two lines to the Host * block (or the top of config if you have no wildcard block yet).
Host *
AddKeysToAgent yes
UseKeychain yes
Then add your key to the agent for this session:ssh-add --apple-use-keychain ~/.ssh/id_ed25519
From the next login onward, macOS loads the key automatically. Linux \
users: most desktop environments start ssh-agent automatically. If yours \
does not, add eval "$(ssh-agent -s)" and ssh-add to your shell profile.UseKeychain yes is a macOS-only option (ignored on Linux). It is what saves the passphrase to the macOS Keychain. AddKeysToAgent yes works on both platforms and tells the agent to hold the key for the session.
Once key-based login is confirmed working, disable password authentication on the server entirely. This removes the single biggest attack vector for a public-facing server.
sudo nano /etc/ssh/sshd_config
Find or add these two lines:PasswordAuthentication no
PubkeyAuthentication yes
Reload the SSH daemon to apply the change. Do not close your existing \
session until you have verified a new login works from a second terminal.sudo systemctl reload sshd
Open a new terminal and run ssh myserver (or use your Host alias). If \
you land at the prompt, you are done. Password login is now blocked for \
everyone, including attackers.Quick reference: files to know. ~/.ssh/id_ed25519 is your private key, never share it. ~/.ssh/id_ed25519.pub is your public key, safe to share. ~/.ssh/authorized_keys (on the server) is where valid public keys live. ~/.ssh/config is your client-side shortcut file.