SSH Connection Failed After Deploy (sshd Crashed)

Published · Last updated: June 2026 · 4 min read

Who this is for

Users who see "SSH connection failed: connect ECONNREFUSED" in the CloudAIPilot terminal immediately after a production deployment — even though the app itself is still running and serving traffic over HTTPS. If the terminal was working fine before the deploy and stopped working right after, this playbook is for you.

What happened

During a production deployment, the server runs a build process (npm install, Next.js build, etc.) that can briefly spike memory usage. On servers with limited RAM, this can cause the Linux OOM (Out of Memory) killer to terminate a background process — and sshd (the SSH daemon) is sometimes the victim.

Key symptom: The app is healthy (you can still open it in a browser) but the CloudAIPilot terminal shows ECONNREFUSED on port 22. The SSH service has died, not the server.

Step 1 — Confirm it is sshd, not a firewall issue

Before attempting a fix, verify the server is actually reachable on port 22:

Open your cloud provider console and check the VM status — it should show Running (green).
Try loading the app itself in a browser — if it responds, the VM is alive.
If the VM is running and the app is serving, but port 22 is ECONNREFUSED (not timed out), the SSH daemon has died. A firewall block would cause a timeout, not a refused connection.

Step 2 — Fix: Reset the VM (recommended)

The fastest fix is to reset the VM. This restarts the operating system without deleting any data or files. Your app will restart automatically via PM2 within ~60 seconds.

Note for AWS / Azure / DigitalOcean users: The steps below use GCP Console and Cloud Shell. If your server is on another provider, use your provider's equivalent "Reboot" or "Restart" button in the VM management console — the effect is identical.

Option A — GCP Console (click-through)

Open GCP Console → Compute Engine → VM instances.
Locate your server.
Click the ⋮ (More actions) menu on the right → Reset.
Confirm. The VM reboots in ~30–60 seconds.
Wait ~90 seconds, then open the CloudAIPilot terminal — it will reconnect automatically.

Option B — GCP Cloud Shell (one command)

If you prefer the command line, open Cloud Shell from the GCP Console (the >_ icon, top-right) and run:

gcloud compute instances reset YOUR_VM_NAME --zone=YOUR_ZONE

Example (replace with your actual VM name and zone):

gcloud compute instances reset my-production-server --zone=us-central1-a

You will see Updated [https://...] when the reset is issued. Wait ~90 seconds, then test the terminal in CloudAIPilot.

Note: The zone is shown in the VM instances list. Double-check whether the zone ends in -a, -b, or -c — the wrong suffix gives a "resource not found" error.

Step 3 — If SSH is still refused after the reset

The VM may have come back up but the SSH key used by CloudAIPilot is not recognised. This can happen if you previously connected using a different key method. In this case you can reconnect from GCP Cloud Shell by injecting a temporary key:

# 1. Generate a new key with no passphrase
rm -f ~/.ssh/google_compute_engine ~/.ssh/google_compute_engine.pub
ssh-keygen -t ed25519 -f ~/.ssh/google_compute_engine -N ""

# 2. Authorise it on the VM via GCP metadata
gcloud compute instances add-metadata YOUR_VM_NAME \
  --zone=YOUR_ZONE \
  --metadata=ssh-keys="YOUR_GOOGLE_USERNAME:$(cat ~/.ssh/google_compute_engine.pub)"

# 3. SSH in
gcloud compute ssh YOUR_VM_NAME --zone=YOUR_ZONE

Replace YOUR_GOOGLE_USERNAME with the username shown in your Cloud Shell prompt (e.g. janesmith in janesmith@cloudshell).

Once inside the VM, restart sshd manually and verify PM2 is running:

sudo systemctl restart sshd
pm2 list

Prevention

If your server has less than 2 GB RAM, consider upgrading the instance type or adding a swap file. Builds that compile TypeScript or bundle large JavaScript projects are memory-intensive and will spike past 1 GB.

To add a 2 GB swap file on Ubuntu (run once on the server):

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

This gives the OOM killer a buffer and significantly reduces the risk of sshd being killed during a deploy.