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.

Practice

1. What is the main purpose of SSH access in Google Cloud Platform (GCP)?

easy

A. To securely connect to virtual machine instances

B. To store large files in the cloud

C. To monitor network traffic

D. To create new virtual machines automatically

Solution

1. Step 1: Understand SSH access

   SSH (Secure Shell) is a protocol used to securely connect to remote machines, such as virtual machines in GCP.

2. Step 2: Identify SSH use in GCP

   In GCP, SSH access allows users to securely log into VM instances to manage and operate them.

3. Final Answer:

   To securely connect to virtual machine instances -> Option A

4. Quick Check:

   SSH access = secure VM connection [OK]

Hint: SSH is for secure remote login to VMs [OK]

Common Mistakes:

• Confusing SSH with storage or monitoring services
• Thinking SSH creates VMs instead of connecting to them

2. Which of the following is the correct way to add an SSH key to a VM instance's metadata in GCP?

easy

A. Add the SSH key to the project billing settings

B. Add the SSH key to the instance's firewall rules

C. Add the SSH key to the VM's disk storage

D. Add the SSH key to the instance's metadata under the 'ssh-keys' key

Solution

1. Step 1: Understand where SSH keys are stored

   SSH keys are stored in metadata, which is a place to keep configuration info for VMs.

2. Step 2: Identify correct metadata key

   The correct metadata key for SSH keys is 'ssh-keys' at the instance or project level.

3. Final Answer:

   Add the SSH key to the instance's metadata under the 'ssh-keys' key -> Option D

4. Quick Check:

   SSH keys stored in 'ssh-keys' metadata [OK]

Hint: SSH keys go in 'ssh-keys' metadata key [OK]

Common Mistakes:

• Adding SSH keys to firewall rules instead of metadata
• Trying to store SSH keys in disk storage or billing settings

3. Given the following metadata setup for a VM instance in GCP:

{"ssh-keys": "user:ssh-rsa AAAAB3Nza... [e-mail]"}

What will happen when you try to SSH into this VM as 'user'?

medium

A. SSH connection will succeed using the provided public key

B. SSH connection will be denied due to missing keys

C. SSH will prompt for a password instead of using keys

D. The VM will restart automatically

Solution

1. Step 1: Analyze the metadata content

   The metadata contains a valid SSH public key for user 'user' under 'ssh-keys'.

2. Step 2: Understand SSH key usage

   When connecting as 'user', the VM checks the 'ssh-keys' metadata and allows access if the matching private key is used.

3. Final Answer:

   SSH connection will succeed using the provided public key -> Option A

4. Quick Check:

   Valid SSH key in metadata = successful SSH login [OK]

Hint: Valid SSH key in metadata allows login [OK]

Common Mistakes:

• Assuming password prompt appears despite key presence
• Thinking VM restarts due to SSH metadata

4. You added an SSH key to your project-wide metadata but still cannot SSH into a VM instance. What is the most likely cause?

medium

A. The firewall allows SSH traffic

B. The VM instance is turned off

C. The instance has block-project-ssh-keys set to true, blocking project keys

D. The SSH key format is incorrect in the metadata

Solution

1. Step 1: Understand project-wide SSH keys

   Project-wide SSH keys apply to all instances unless blocked by instance settings.

2. Step 2: Check instance metadata blocking

   If the instance metadata has 'block-project-ssh-keys' set to true, it ignores project-wide keys.

3. Final Answer:

   The instance has block-project-ssh-keys set to true, blocking project keys -> Option C

4. Quick Check:

   block-project-ssh-keys=true blocks project keys [OK]

Hint: Check 'block-project-ssh-keys' flag on instance [OK]

Common Mistakes:

• Assuming firewall allows SSH means keys work
• Ignoring instance-level metadata blocking project keys

5. You want to ensure that only specific users can SSH into a VM instance in GCP, even though project-wide SSH keys exist. Which approach is best?

hard

A. Add all users' SSH keys to project metadata and leave instance metadata empty

B. Set 'block-project-ssh-keys' to true on the instance and add allowed users' keys to instance metadata

C. Remove all SSH keys from project metadata and rely on firewall rules

D. Disable SSH access entirely on the VM instance

Solution

1. Step 1: Understand project-wide vs instance metadata

   Project-wide SSH keys apply to all instances unless blocked by instance settings.

2. Step 2: Control access per instance

   Setting 'block-project-ssh-keys' to true on the instance disables project keys, allowing only instance metadata keys.

3. Step 3: Add allowed users' keys to instance metadata

   By adding only allowed users' keys to instance metadata, you restrict SSH access to them.

4. Final Answer:

   Set 'block-project-ssh-keys' to true on the instance and add allowed users' keys to instance metadata -> Option B

5. Quick Check:

   Block project keys + instance keys = controlled SSH access [OK]

Hint: Block project keys, use instance keys for control [OK]

Common Mistakes:

• Relying only on firewall rules for SSH user control
• Removing project keys without adding instance keys
• Disabling SSH entirely when access is needed