SSH In Depth

Give each key a name that tells you what it's for, so you can pick out the right one later in ~/.ssh, in 1Password, and in a server's authorized_keys. (1Password can also create keys for you; see section 3.)

• Describe what it's for: a client, a group of servers, or a purpose. For example client-a, moodle-servers, or multipass-vms.
• Lowercase letters, numbers, and dashes. No spaces.
• On this sheet the name is shown as key-name. Replace it with your own name in every command.

• If a file with your chosen name is already there, pick a different name. Using the same name would replace that key.
• No such file or directory = you have no keys yet. That's fine; go on.

No Copy button on purpose: type it with your own name in both places.

• The public key is one long line: type, the key itself, then your label.
• pbcopy is a Mac command that puts it on the clipboard, ready to paste. Note it's the .pub file, never the private one.

Keys live in the hidden .ssh folder in your home folder (~/.ssh). ssh refuses to use keys that other people on the computer could read, so the permissions matter.

• && means "then, if that worked, do the next one."
• No output = done. No matches found: *.pem just means you have no .pem files in that folder.

Folders starting with a dot are hidden. Either type open ~/.ssh in Terminal, or in Finder press Cmd+Shift+. (period) to show hidden files.

1Password stores each private key and hands it to ssh when you log in, after a Touch ID or password check. The keys are backed up with the rest of your vault and don't need to sit loose on your Mac.

1. Add the key: in 1Password, New Item › SSH Key. Import an existing key file, or generate a new ed25519 key there.
2. Put it in your Personal vault (called Private on some accounts). By default the SSH agent only looks there. A key in any other vault is ignored.
3. Turn on the agent once: Settings › Developer › Use the SSH Agent.
4. Point each server entry at 1Password in your config file. That's section 4.

Built in, nothing to install. The key stays as a file in ~/.ssh, and your Mac remembers its passphrase after ssh-add --apple-use-keychain ~/.ssh/key-name. Fine for one or two keys, but you have to back the files up yourself.

A plain text file of shortcuts, one entry per server. It lets you type ssh ubuntu1 instead of a long command with an address, user name, and key.

• Indenting is just for looks. Spaces or tabs, any amount.
• A line starting with # is a note to yourself; ssh ignores it.
• Several servers can share one key: give each entry the same IdentityFile.
• Entries that still point to a private key file (like a .pem) keep working. You can switch servers to 1Password one at a time.

Switching one server to 1Password

One command per box. Run them one at a time.

No output = done. To undo any change later, copy it back: cp ~/.ssh/config.backup ~/.ssh/config.

Reads the private key and saves its public half. Use the real path from that entry's current IdentityFile line. No output = done.

Compare the SHA256: part with the fingerprint field of the key in 1Password. The first 6 to 8 characters matching is enough. Also check the key is in your Personal/Private vault.

In that entry, change IdentityFile to the .pub file, and add the IdentitiesOnly and IdentityAgent lines shown at the top of this section. Leave Host, HostName, and User alone. Save: Ctrl+O, Enter. Exit: Ctrl+X.

A 1Password window asks to allow ssh; approve it, and you're in. Type exit to log out. If it fails, see Troubleshooting.

To log in with your key, the server needs your public key in its authorized_keys file. How you get it there depends on whether the server is new or already running.

A. New server: give AWS your public key, pick it at launch

1. Once per AWS region: in the AWS console, go to EC2 › Key Pairs › Actions › Import key pair.
2. Give it a name you'll recognize, and paste in your public key (the one line from your .pub file; pbcopy < ~/.ssh/key-name.pub copies it). Never paste the private key.
3. When launching a server, choose that key pair. AWS puts your public key into the server's authorized_keys on first boot.

• Key pairs belong to one region. A server in another region needs the key imported there too.
• Since you're importing your own key, AWS never has your private key, and there's no .pem to download or lose.

B. Existing server: add your key to authorized_keys

You log in the way you do today (with the old key), add your new public key as an extra line, then test. The old key keeps working until you decide to remove it.

Puts the public key on your clipboard. No output = done.

You'll see one or more long lines starting with ssh-rsa or ssh-ed25519. Don't change them. Use the down arrow to go to the very end, make sure you're on a new empty line, and paste with Cmd+V. Save: Ctrl+O, Enter. Exit: Ctrl+X.

~/.ssh/authorized_keys means the same thing on either, once you're logged in as that user.

First switch the server's config entry to the new key (section 4), then in a new Terminal window:

• Logs in (after the 1Password approval) = done. Close the old window.
• Permission denied = something's off, but your first window is still logged in, so you can fix authorized_keys from there. That's why you keep it open.

Lines starting with # are notes. Put one above each key, so later you know whose it is:

Every server has its own ID (its host key). The first time you connect, your Mac saves that ID in ~/.ssh/known_hosts. After that, if the ID ever changes, ssh refuses to connect, in case someone is pretending to be your server.

• Expected: you replaced or rebuilt the server, moved an Elastic IP to a new server, or a Multipass machine got an address another one used before.
• Not expected: nothing changed that you know of. Stop and find out before connecting.

• Use the server's address (its HostName), not its nickname; known_hosts stores addresses.
• It removes just that one entry and saves a backup as known_hosts.old.
• Then connect again and answer yes to save the new ID.

Both use the same login as ssh, so your config nicknames and 1Password work here too. Pattern: FROM TO, with server: in front of a path on the server.

• -a keeps dates and permissions; -v lists each file as it goes.
• A trailing / on the source means "the contents of this folder." Without it, you get the folder itself inside the destination.

You can't put sudo in front of scp. Log in, copy the file somewhere you can read with sudo cp, then download that copy:

Delete the copy from /tmp when you're done.

Delete their line from authorized_keys. That's all it takes, as long as they had their own key. If they used a key you also use (like a shared .pem), you have to give yourself a new key first.

• Replace vendor-key with the label at the end of their key line.
• sudo sh -c '…' runs the whole search as root, so it can look inside every user's private .ssh folder.
• Each match shows the file, then the line number. No such file for /root is fine.

Use the exact file path from step 1. Move to their line (and its # note). Ctrl+K cuts a whole line. Save: Ctrl+O, Enter. Exit: Ctrl+X.

Keep that window open and run ssh ubuntu1 in a new Terminal window, exactly as in section 5.

A security group is AWS's firewall for a server. SSH uses port 22. Even with perfect keys, port 22 should only be open to the addresses that need it, not the whole internet.

AWS console: EC2 › Security Groups › pick the group › Inbound rules › Edit inbound rules. The Source › My IP option fills in your current address.