Hi @SumanthBurla,
Welcome to Google Cloud Community!
Metadata can be configured at both the project and instance levels. Project-level metadata applies to all virtual machine instances in the project, while instance-level metadata affects only that specific instance. If the same key is set at both levels, Compute Engine will give precedence to the instance-level metadata.
This means:
- If you set metadata only at the project level, it will be automatically propagated to all instances.
- If metadata is set at the instance level, it will take priority over project-level metadata, and the project-level settings will not be applied.
If someone modifies the SSH keys at the instance level, those instance-specific keys will override any project-level keys. This could explain why SSH access works when you add the key directly to the instance but fails when relying on the project-level metadata. The issue might be due to the key being removed or changed at the project level, or because the instance-level keys are taking precedence.
The issue of inconsistent SSH access due to metadata refresh problems is significantly amplified when multiple users access the same VM. If users add or remove SSH keys directly to the VM, it can lead to conflicting configurations, making it difficult to manage access control. One user's action might inadvertently break SSH for others.
Ensure that the correct SSH key is added to both the project metadata and the instance metadata (if applicable), and verify that file permissions and network configurations are correct.
For more details, you may refer to the following documentation:
I hope the above information is helpful.
LinkedIn
Twitter
