All the instances in your project are configured with the custom metadata enable-oslogin value set to FALSE and to block project-wide SSH keys. None of the instances are set with any SSH key, and no project-wide SSH keys have been configured. Firewall rules are set up to allow SSH sessions from any IP address range. You want to SSH into one instance.
What should you do?
Given that the instances are configured with the enable-oslogin set to FALSE and project-wide SSH keys are blocked, there are no SSH keys configured at the instance or project level. The gcloud compute ssh command in Cloud Shell utilizes IAM permissions and temporary SSH keys to provide access, bypassing the need for pre-configured SSH keys on the instance. This method allows you to SSH into the instance without modifying any metadata settings or adding SSH keys manually.
A is worked, I have tested as below 1) Created VM 2) Set enable-oslogin FALSE ( in compute engine metadata) as well in VM's metadata 3) None of the instances are set with any SSH key, and no project-wide SSH keys have been configured (set block project wide ssh key on VM) 4) firewall allow for tcp:22 5) Try to ssh from cloud shell and web console, worked able to ssh into VM 5)
Thank you for sharing detailed steps, Agree with A.
Correct answer A . D is incorrect - it mentions that you are adding the ssh key to the project, but the question says "block project-wide SSH keys." therefore that ssh key will not be added to the instance.
B is correct: Since the custom metadata enable-oslogin value is set to FALSE, SSH access using an SSH key pair is blocked, and there are no project-wide SSH keys configured. In this case, we need to enable OS Login to log in to the instance using our Google Cloud account credentials instead of SSH keys. Option A is incorrect because we cannot SSH into the instance using gcloud compute ssh since the instances are not configured to allow SSH access using SSH keys. Option C is incorrect because adding an SSH key pair to the instance would not work since the instance is configured to block SSH access using keys. Option D is incorrect because adding a public key to the project would not allow SSH access to the instance since the instance is not configured to allow SSH access using keys.
Answer is A
A, gcp cloud shell automatical deploy ssh key on instance.
Correct answer A
A is correct answer
A: OS Login provides the following benefits: • Automatic Linux account lifecycle management - You can directly tie a Linux user account to a user's Google identity so that the same Linux account information is used across all instances in the same project or organization.
You only need to login to one instance, the question is asking for a permanent change in your environment, just login to one instance (maybe temporarily?) .. So A makes sense and would be the only option
*the question is NOT asking for a permanent change
The only answer that works is A. B) If you enable OS Login then you have to upload an SSH public key to your Google profile as described here: https://cloud.google.com/compute/docs/instances/ssh#third-party-tools_1 C) You should never upload your private SSH key to Google D) Project SSH keys are disabled, so this will not work A) This approach works by creating an SSH key pair, uploading the public key to the instance and saving the private key in your local profile. Read the details here: https://cloud.google.com/compute/docs/instances/ssh
Choose Option A. Custom Metadata Configuration: The instances in your project have the custom metadata enable-oslogin set to FALSE. This indicates that Google Cloud Identity-Aware Proxy (IAP) is not enabled for these instances. With IAP disabled, you typically use SSH keys to authenticate. Project-wide SSH Keys are Blocked: The project-wide SSH keys are blocked, so adding a public key to the project metadata won't work. Third-Party Tool: The option doesn't involve setting any custom metadata or changing instance configurations. Instead, it suggests using the built-in gcloud compute ssh command, which simplifies the SSH process. Cloud Shell: Opening the Cloud Shell provides you with an environment where the Google Cloud SDK is pre-installed, including the gcloud command-line tool. It eliminates the need to install any third-party tools on your local machine.
A) works, because a SSH key is automatically generated and propagated by GCloud tool to the instance metadata (verified in GCloud). Because B) doesn't mention any SSH key generation and upload sequence, it will likely NOT work (didn't test this myself) Of course, SSH via direct click on the 'SSH' button via the web UI also works, in this case a web-ui-ssh specific key is added to the instance.
Answer is C...
i don't understand how A is the correct one, i believe it should be D, since OSLOGIN is disabled and there are no keys, and IAP is not mentioned either- trying to use gcloud doesnt seem logically like it would work to me, i understand some people tested it and it does work, i'm just saying its not intuitive
i think its D, since OSLOGIN is set to false ,how would you use GCP to connect? sounds like it should be 'standalone' login
it is A Cloud Shell and gcloud compute ssh: The gcloud compute ssh command in Cloud Shell uses IAM permissions and temporary SSH keys to provide access to instances. This method bypasses the need for pre-configured SSH keys on the instances or project-wide SSH keys.
Cloud Shell and gcloud compute ssh: The gcloud compute ssh command in Cloud Shell uses IAM permissions and temporary SSH keys to provide access to instances. This method bypasses the need for pre-configured SSH keys on the instances or project-wide SSH keys.