Don't open port 22 in GCE

When deploying servers on Google Compute Engine, it’s common to expose port 22 (SSH) on the internet for convenience. While this seems harmless — especially since Google’s tooling manages SSH keys automatically — it introduces a significant and often-overlooked security risk.

Let’s break down why this happens and how to fix it.

The Problem with Open SSH Ports

By default, when you connect using the “Connect” button in the Cloud Console or via

gcloud compute ssh <instance-name>

Google Cloud generates a temporary SSH key and places it in your user’s ~/.ssh/authorized_keys file inside the VM. This key is short-lived and automatically cleaned up — so far, so good.

However, if your firewall rule allows inbound SSH (port 22) from “0.0.0.0/0”, that means anyone in the world can attempt to connect to your instance. Even if your keys are secure, automated bots will continuously scan and brute-force open SSH ports. If at any point a user or setup script creates an account with a weak or password-based login, your server becomes vulnerable.

Level 1: Restrict SSH to IAP

If your instance has a public IP, there’s no need to open SSH to the entire internet. Instead, restrict access to Google’s Identity-Aware Proxy (IAP).

IAP acts as a secure gateway that lets you connect to your VM over Google’s infrastructure rather than directly from the public internet. You can do this by allowing SSH only from IAP’s IP ranges in your firewall rule.

gcloud compute firewall-rules create allow-ssh-from-iap \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=allow-ssh

With this setup:

The “SSH” button in the Console and gcloud compute ssh both continue to work.
Connections occur through IAP, not the public internet.
Port 22 remains invisible to the rest of the world.

Level 2: Remove the Public IP Entirely

For even stronger isolation, you can create a Compute Engine VM without a public IP address. The instance still needs outbound internet access (for updates, APIs, etc.), which you can provide through a Cloud NAT gateway.

Your setup would look like this:

VM without a public IP
Outbound traffic through Cloud NAT
SSH access through IAP (same firewall rule as above)
Inbound application traffic (HTTP, HTTPS, etc.) routed through Cloud CDN or an HTTPS Load Balancer

This approach ensures:

Your VM is not exposed to the public internet at all.
All traffic flows through Google’s managed edge network.
SSH and application access remain fully functional via secure, audited channels.

Summary

Level	Description	SSH Access	Public Exposure
1	Public IP + SSH restricted to IAP	via IAP	Only port 22 (restricted)
2	No Public IP + Cloud NAT + IAP	via IAP	None

Final Thoughts

Leaving SSH open to the world may seem convenient, but it’s a long-term liability. Restricting SSH to IAP, or removing the public IP altogether, significantly reduces your attack surface while preserving full functionality.

Whenever possible, treat your servers as private infrastructure — accessible only through secure, identity-aware channels.

Have some thoughts, or need help securing your GCE instances? Contact us at info@siocode.hu.