A complete walkthrough for connecting your Mac terminal to your VMware Fusion VM, logging in with keys instead of passwords, and cloning course repositories from GitHub inside the VM.
Two separate SSH relationships. Keeping them straight is half the battle — see the key rule at the end of Part 2.
Goal: the VM runs an SSH server and you know its IP address. Do these steps in the VMware Fusion console window — you can't SSH in until this is done.
sudo apt update && sudo apt install -y openssh-server
sudo systemctl enable --now ssh
Ubuntu Server usually ships with openssh-server preinstalled, but the command is idempotent — running it again changes nothing if it's already there. enable --now does two jobs at once: starts the service immediately and registers it to start at every boot. Skip the enable half and SSH silently dies after your next reboot.
ip -4 addr show
Look for the network interface (usually ens160 on Fusion) and note its address — typically something like 192.168.x.x.
Fusion's default networking mode is NAT ("Share with my Mac"). The VM gets a private IP that only your Mac can reach — exactly what you want for a lab machine. The IP usually survives reboots via its DHCP lease, but it can change. "SSH suddenly stopped working after a reboot" is almost always a changed IP.
ping -c 3 192.168.x.x
If ping succeeds, the network path is fine — so any SSH failure after this is an SSH problem (service, keys, permissions), not a network problem (IP, adapter mode). This one check cuts your debugging space in half.
Goal: log in from your own terminal, then switch to key-based login so you never type the VM password again — and VS Code Remote-SSH works out of the box.
ssh yourusername@192.168.x.x
You'll be asked to confirm the server's host-key fingerprint. Type yes.
Your Mac has never seen this server before, so SSH asks you to trust its public host key, then stores it in ~/.ssh/known_hosts. On every future connection it silently verifies you're talking to the same machine — this is SSH's defense against man-in-the-middle attacks.
This is the mechanism above firing. It happens when you re-create your VM — the new VM has a new host key, and your Mac still remembers the old one. Fix by forgetting the old entry, then connect again:
ssh-keygen -R 192.168.x.x
Generate a keypair on the Mac (skip if you already have one — check with ls ~/.ssh):
ssh-keygen -t ed25519 -C "name@email.address"
Accept the default path (~/.ssh/id_ed25519). A passphrase is optional. Then copy the public key to the VM:
ssh-copy-id yourusername@192.168.x.x
ssh-copy-id appends your public key to ~/.ssh/authorized_keys on the VM with the correct permissions. Your private key never leaves your Mac. From now on, the server issues a mathematical challenge that only your private key can answer — no password crosses the wire at all. We use ed25519 because it's the modern default: fast, secure, and short keys.
On the Mac, create or edit ~/.ssh/config:
Host csce313
HostName 192.168.x.x
User yourusername
IdentityFile ~/.ssh/id_ed25519
Now ssh csce313 just works — no IP, no username, no flags.
VS Code's Remote-SSH extension reads this exact file. Once the config entry exists, csce313 shows up by name in the Remote Explorer sidebar, and you can open folders on the VM directly in VS Code. This is the piece that makes the whole workflow seamless.
Goal: the VM can clone course repositories. The VM is a separate machine from your Mac — it needs its own identity to GitHub.
git clone https://github.com/org/repo.git
Public repos clone with no credentials at all. Private repos over HTTPS will prompt for a personal access token — clunkier, which is why Option B exists.
ssh-keygen -t ed25519 -C "name@email.address"
cat ~/.ssh/id_ed25519.pub
Copy the entire output line, then in a browser: GitHub → Settings → SSH and GPG keys → New SSH key → paste → save.
ssh -T git@github.com
The expected output is Hi username! You've successfully authenticated, but GitHub does not provide shell access. Students routinely misread the second half as a failure. It isn't — GitHub is simply telling you it only speaks git, not interactive shells. If you see your username, you're done.
git clone git@github.com:org/repo.git
Match the exact error message to its cause. Most SSH problems are one of these five.
| Symptom | Root cause | Fix |
|---|---|---|
Connection refused |
sshd not running on the VM, or wrong IP | On the VM console: sudo systemctl status ssh; restart with sudo systemctl restart ssh |
Connection timed out |
Wrong IP, or VM network adapter not in NAT mode | Re-check ip -4 addr show on the VM; verify Fusion → Settings → Network Adapter → "Share with my Mac" |
Permission denied (publickey) from GitHub |
Key not added to GitHub, or key was generated on the Mac while cloning from the VM | Run cat ~/.ssh/id_ed25519.pub on the VM and add that key to GitHub |
Password still asked after ssh-copy-id |
Broken permissions — sshd refuses keys in world-readable files by design | On the VM: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys |
| SSH worked yesterday, fails after reboot | DHCP handed the VM a new IP | Get the new IP with ip -4 addr show, update ~/.ssh/config |