SSH access and metadata in GCP - Step-by-Step Execution

Process Flow - SSH access and metadata

Start: VM Instance Created

↓

Set Metadata: SSH Keys

↓

User Tries SSH Access

↓

Check Metadata for SSH Keys

↓

Access Denied

↓

Authenticate User

↓

Grant SSH Access

↓

User Connected to VM

This flow shows how SSH access to a VM is controlled by metadata containing SSH keys. The system checks metadata for keys before allowing access.

Execution Sample

GCP

gcloud compute instances add-metadata my-vm --metadata ssh-keys="user:ssh-rsa AAA..."

This command adds SSH keys to the VM metadata to allow user SSH access.

Process Table

Step	Action	Metadata SSH Keys Present?	Result	User Access
1	VM instance created	No	No SSH keys set	Access denied
2	Add SSH keys to metadata	Yes	SSH keys stored in metadata	Access pending
3	User attempts SSH login	Yes	Metadata checked for keys	Authentication started
4	User key matches metadata	Yes	User authenticated	Access granted
5	User connected via SSH	Yes	Connection established	User logged in
6	User attempts SSH login without keys	No	No keys found	Access denied

💡 Execution stops when user is either granted access or denied due to missing keys.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Metadata SSH Keys	None	Set with user key	Checked	Matched	Present
User Access	Denied	Pending	Authenticating	Granted	Logged In

Key Moments - 3 Insights

Why does the user get denied access at step 1?

Because no SSH keys are set in the metadata yet, so the system cannot authenticate the user (see execution_table row 1).

What happens if the user tries to SSH without matching keys in metadata?

The system denies access since it cannot find a matching key in metadata (see execution_table row 6).

How does metadata control SSH access?

Metadata stores SSH keys that the system checks during login to authenticate users (see execution_table steps 2-4).

Visual Quiz - 3 Questions

Look at the execution table, what is the user access status at step 3?

A Access granted

B Authentication started

C Access denied

D No SSH keys set

💡 Hint

Check the 'User Access' column at step 3 in the execution_table.

At which step does the metadata first contain SSH keys?

A Step 2

B Step 4

C Step 1

D Step 6

💡 Hint

Look at the 'Metadata SSH Keys Present?' column in the execution_table.

If the metadata SSH keys were removed after step 4, what would happen at the next SSH attempt?

A User would authenticate automatically

B User would still be granted access

C User would be denied access

D User would bypass authentication

💡 Hint

Refer to execution_table row 6 where no keys cause access denial.

Concept Snapshot

SSH access to a VM in GCP is controlled by metadata containing SSH keys.
Users must have their public SSH key added to the VM's metadata.
When a user tries to SSH, the system checks metadata for matching keys.
If a match is found, access is granted; otherwise, access is denied.
Managing SSH keys via metadata is a secure way to control VM access.

Full Transcript

This visual execution shows how SSH access to a Google Cloud VM depends on metadata containing SSH keys. Initially, the VM has no SSH keys set, so users cannot connect. When SSH keys are added to the VM's metadata, users with matching keys can authenticate and gain access. The system checks metadata during each SSH attempt. If keys are missing or do not match, access is denied. This process ensures secure and controlled SSH access to cloud VMs.