Accessing VMs

Administrators normally connect to private VMs with the gcloud CLI or Google Cloud Console browser-based SSH. Both can use Identity-Aware Proxy (IAP), avoiding a public VM address or an SSH rule open to the internet.

1. Prepare Access

Install the Google Cloud CLI, authenticate, and select the intended project:

gcloud auth login
gcloud config set project YOUR_GCP_PROJECT_ID
gcloud config list

An administrator must grant permission to establish IAP tunnels and log in to the target VM. Common roles include:

  • roles/iap.tunnelResourceAccessor for the IAP tunnel;
  • roles/compute.osLogin, or roles/compute.osAdminLogin when sudo access is required.

Exact bindings depend on organizational policy. Do not add broad project roles merely to make SSH work.

2. Use a Terminal SSH Session

This is the normal method for administration, service checks, log review, and configuration changes:

gcloud compute ssh YOUR_VM_NAME \
  --project=YOUR_GCP_PROJECT_ID \
  --zone=YOUR_GCP_ZONE \
  --tunnel-through-iap

If the connection fails, verify the active account and project, VM name and zone, IAP and OS Login roles, and the firewall allowance for IAP TCP forwarding.

3. Optionally Forward Private Web Services

SSH port forwarding makes a service bound to the VM available only through the active SSH connection. This is useful for viewing ERDDAP in a local browser before public routing is ready, or for reaching an optional browser-based tool without opening its port to the network.

ERDDAP only

The following maps local port 8081 to Tomcat port 8080 on the VM:

gcloud compute ssh YOUR_ERDDAP_VM_NAME \
  --project=YOUR_GCP_PROJECT_ID \
  --zone=YOUR_GCP_ZONE \
  --tunnel-through-iap \
  --ssh-flag='-4 -L 8081:localhost:8080'

While the SSH session remains open, visit http://localhost:8081/erddap/. If local port 8080 is free, -L 8080:localhost:8080 is equally valid.

JupyterLab when installed

Jupyter is not required for ERDDAP. Some teams install it on a processing or development VM for interactive work. Start it on the VM’s loopback address:

jupyter lab --no-browser --ip=127.0.0.1 --port=8888

Then forward local port 8888 from another terminal:

gcloud compute ssh YOUR_VM_NAME \
  --project=YOUR_GCP_PROJECT_ID \
  --zone=YOUR_GCP_ZONE \
  --tunnel-through-iap \
  --ssh-flag='-4 -L 8888:localhost:8888'

Use the tokenized http://localhost:8888/lab?... URL printed by Jupyter.

Combined tunnel

When both services intentionally run on the same VM, one SSH session can forward both ports:

gcloud compute ssh YOUR_VM_NAME \
  --project=YOUR_GCP_PROJECT_ID \
  --zone=YOUR_GCP_ZONE \
  --tunnel-through-iap \
  --ssh-flag='-4 -L 8081:localhost:8080 -L 8888:localhost:8888'

Omit any forwarding rule for a service that is not installed. Interactive processing can compete with ERDDAP for memory and CPU, so use a separate processing VM when the workload is substantial.

4. Use Browser-Based SSH

Browser SSH is useful for a quick terminal session when the local CLI is unavailable:

  1. Open the Google Cloud Console.
  2. Select the correct project from the project selector at the top of the page.
  3. Open the navigation menu and choose Compute Engine → VM instances.
  4. Find the target VM in the VM instances table.
  5. In that row’s Connect column, click SSH.
  6. Allow the browser terminal to open and complete any organization login prompt.

Browser SSH provides terminal access. It does not create the local browser port forwards shown above and is not ideal for a long-running administrative session.