SSH keys

What SSH actually does

SSH, the Secure Shell, solves two separate problems every remote login has:

• Privacy. Everything between the two machines is encrypted. Whoever is on the same Wi-Fi sees traffic, but not your commands, your output or your password. This part is automatic; you never configure it.
• Identity, twice. First the server proves who it is to you, then you prove who you are to the server. Today's page is about upgrading the second half from passwords to keys.

Step 1 explains something you already lived through. Every SSH server, your Pi included, generated its own host key pair at first boot. The first time you connect, your client shows that key's fingerprint and asks whether to trust it; say yes and it is stored in ~/.ssh/known_hosts. From then on the check is silent, and it protects you against connecting to an impostor machine: if the key ever changes unexpectedly, SSH refuses loudly. So the Pi has keys about itself (host keys), and today you add keys about you (user keys). Same mathematics, two different questions.

The key-pair idea

Why can the public half be public? The pair is asymmetric: what one key locks, only the other unlocks. Think of the public key as an open padlock you can hand out freely; anyone can snap it shut on a challenge, but only your private key opens it. When you connect, the server locks a random challenge with your public key, and producing the answer proves you hold the private key, which itself is never transmitted. Nothing to guess, nothing to shoulder-surf, nothing to reuse from a leaked password list. A password, by contrast, is a shared secret: the server must hold something derived from it, and you retype it on every machine, which is exactly what makes it phishable and reusable.

Generate a pair on the lab PC

On the lab PC (Windows PowerShell, macOS Terminal or Linux terminal). ed25519 is the modern, short, fast key type:

$ ssh-keygen -t ed25519 -C "lab-pc"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):   # Enter = default
Enter passphrase (empty for no passphrase):                              # see below

• Accept the default file name. Tools look for it there.
• The -C comment just labels the key ("lab-pc", "home-laptop") so you can tell them apart later.
• Passphrase: it encrypts the private key file itself, a second layer if the file is stolen. On a shared lab PC, set one; on your own laptop it is your call. Empty is allowed.
• Result: ~/.ssh/id_ed25519 (private, red in the diagram) and ~/.ssh/id_ed25519.pub (public, green).

Install it on the Pi

ssh-copy-id appends your public key to ~/.ssh/authorized_keys on the Pi, with the right permissions. It asks for your Pi password one last time:

$ ssh-copy-id username@lastname-pi.local    # your-username@your-hostname.local
Number of key(s) added: 1
$ ssh username@lastname-pi.local            # test: no password prompt (a passphrase prompt is the key's, not the Pi's)

If ssh-copy-id is missing (some Windows setups), do it by hand; this is exactly what the tool automates:

$ type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@lastname-pi.local "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"   # PowerShell

A key for GitHub

Same idea, other direction: the Pi generates a pair, and GitHub holds the public half, so pushes from the Pi need no password or token typing. On the Pi:

1. Generate and show the public key

   $ ssh-keygen -t ed25519 -C "lastname-pi"
   $ cat ~/.ssh/id_ed25519.pub
   ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... lastname-pi

   Select the whole output line and copy it.

2. Add it on the site

   GitHub → your profile photo → Settings → SSH and GPG keys → New SSH key. Title: lastname-pi. Paste the line. GitHub's own walkthrough with current screenshots: Connecting to GitHub with SSH.

3. Test the connection

   $ ssh -T git@github.com
   Hi username! You've successfully authenticated, but GitHub does not provide shell access.

   That sentence is success. Accept the fingerprint prompt the first time with yes.

4. Use the SSH address for your repository

   $ git clone git@github.com:username/a1-repo.git       # SSH form, not https://
   $ git remote set-url origin git@github.com:username/a1-repo.git   # switch an existing clone

   An https:// remote keeps asking for credentials; the git@github.com: form uses your new key. You will push with it during the Assignment 1 demo.

Key hygiene

• Never copy, mail, commit or screenshot the private key (the file without .pub). Not to your teammate, not to a repository, not to the teacher.
• Sharing the .pub file or a fingerprint (ssh-keygen -lf ~/.ssh/id_ed25519.pub) is always safe.
• Permissions matter: ~/.ssh must be 700 and key files 600, or SSH refuses to use them. ssh-keygen and ssh-copy-id set this correctly; hand-copied files sometimes need chmod 600 ~/.ssh/authorized_keys.
• One pair per machine, a comment naming the machine, and delete a machine's key from the Pi and GitHub when you stop using that machine. Removal is just deleting its line from authorized_keys or the GitHub list.
• If a private key may have leaked, you do not "change its password": you delete the pair, generate a new one, and remove the old public key everywhere it was installed.

Checklist for this stage

• Key pair exists on the lab PC (~/.ssh/id_ed25519 and .pub)
• ssh-copy-id reported a key added, and ssh username@lastname-pi.local logs in with no Pi password prompt
• Key pair exists on the Pi and its .pub line is added on GitHub under a clear title
• ssh -T git@github.com answers "Hi username!"
• The Assignment 1 repository remote uses the git@github.com: form
• I did not copy, send or commit any private key file

Check yourself