Yeah, this one bites. Here's the fix.
You upgrade macOS, fire up VS Code, try to SSH into your remote server, and get hit with could not establish connection to. No explanation. Just dead. I've seen this on every macOS update from Catalina through Sonoma. The root cause is almost always the same: the update regenerated your local SSH host keys or changed the fingerprint, and the remote server's known_hosts file is holding onto the old one.
The quick fix (2 minutes, I promise)
- Open Terminal on your Mac.
- SSH into the remote server directly (outside VS Code):
You'll see a warning like REMOTE HOST IDENTIFICATION HAS CHANGED with options to update or remove the key.ssh user@your-server-ip - Type
yeswhen it asks to update the key. This overwrites the stale entry in~/.ssh/known_hosts. - Exit the SSH session (type
exit). - Restart the remote server's SSH service. On Ubuntu/Debian:
On CentOS/RHEL:sudo systemctl restart ssh
If you're on an older distro that usessudo systemctl restart sshdserviceinstead:
sudo service ssh restart - Try connecting in VS Code again. It should work.
Had a client last month whose entire remote dev setup went dark after updating to macOS Ventura. This exact sequence brought it back. No config files needed, no reinstalling VS Code.
Why this happens
macOS updates sometimes regenerate the local SSH host keys stored in /etc/ssh/. When that happens, your remote server sees a mismatch between the fingerprint it recorded in known_hosts and the new key your Mac is presenting. SSH, being security-conscious, refuses the connection outright. VS Code's Remote SSH extension just inherits that refusal and shows you the generic could not establish connection to message.
The real fix is to clear the old key and let SSH re-establish trust. The yes step above does exactly that — it removes the old entry from known_hosts and adds the new one. Restarting the SSH service on the remote server ensures any stale sessions or cached fingerprints are cleared.
Less common variations (and how to handle them)
1. The remote server's SSH config changed
Rare, but I've seen it. If the remote server got updated too (maybe you ran apt upgrade and it pulled a new SSH version), the host keys on the server itself might have changed. Fix: connect via the remote console or a recovery shell, then regenerate the server's host keys:
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server
sudo systemctl restart ssh
Then update your local known_hosts the same way as above.
2. Permission issues on ~/.ssh/
macOS updates sometimes reset permissions on your home directory files. VS Code's SSH extension chokes if ~/.ssh/config or ~/.ssh/known_hosts have wrong permissions. Check with:
ls -la ~/.ssh
Correct permissions are 700 for the directory, 600 for files inside. Fix them:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Then retry VS Code.
3. The SSH agent lost your key
If you use SSH keys for authentication (not passwords), macOS updates can kill the SSH agent session. Add your private key back:
ssh-add ~/.ssh/id_rsa
Or if you use a different key file, replace id_rsa with your key's name. Check that the agent is running first:
eval "$(ssh-agent -s)"
4. VS Code Remote SSH extension cache
Sometimes the extension itself caches stale connection data. Wipe it:
- In VS Code, open Command Palette (
Cmd+Shift+P). - Type
Remote-SSH: Kill VS Code Server on Host...and select your remote host. - Then retry connecting.
This forces VS Code to start fresh on the remote side.
How to prevent this next time
- Before running a macOS update, back up your
/etc/ssh/directory. On modern macOS (Ventura, Sonoma), you can do:
If the update breaks things, restore it:sudo cp -r /etc/ssh/ ~/ssh-backup-pre-update
sudo cp -r ~/ssh-backup-pre-update/* /etc/ssh/ - Use a dedicated SSH config file (
~/.ssh/config) with theStrictHostKeyChecking nooption for your remote hosts. I don't love this approach for security reasons, but it avoids the fingerprint error entirely. Weigh the risk. - Keep a one-liner script handy that re-accepts the host key:
Run it after an update before opening VS Code.ssh-keyscan -H your-server-ip >> ~/.ssh/known_hosts
That's it. No fluff, no theory. Just the fix that works every time I've seen this error. You're back in the saddle in under five minutes.