7

We have a user that is allowed to SSH into an VM on the Google Cloud Platform.

His key is added to the VM and he can SSH using

gcloud compute ssh name-of-vm

However connecting in this way will always have gcloud try to update project wide meta data

Updating project ssh metadata...failed

It fails because he only has rights for accessing & administrating this VM

However it's very annoying that every time he has to connect in this way he has to to wait for GCP trying to update metadata, which is not allowed and then check the sshkeys on the machine.

  1. Is there a flag in the command to skip checking/updating project wide ssh keys?

Yes we can 'block project wide ssh keys' on the instance, but that would mean that other project admins cannot log in anymore.

I've also tried to minimise access to this user.

  1. But, ideally, what rights should he have if he is allowed to SSH to the machine, start & stop the instance and store data into a bucket?
Tom Lous
  • 2,819
  • 2
  • 25
  • 46

3 Answers3

2

What you can do is to enable-oslogin for all the users you need including admins, enabling OS Login on instances disables metadata-based SSH key configurations on those instances.

The role to start, stop and connect via SSH to an instance would be roles/compute.instanceAdmin (take in account that this role is currently in beta) you can check here a list of the Compute Engine roles available so you can choose the one that better suits your needs.

To store data into a bucket, I think the most suitable role is roles/storage.objectCreator that allows users to create objects but not to delete or overwrite objects.

Pauloba
  • 566
  • 2
  • 14
1

I found this solution very useful.

  1. Create a file called config under ~/.ssh
  2. Add the following to it. Change nickname to anything you prefer, $IP_OF_INSTANCE to the public IP of the instance, and $USER to your machine username.
Host nickname
    HostName $IP_OF_INSTANCE
    Port 22
    User $USER
    CheckHostIP no
    StrictHostKeyChecking no
    IdentityFile ~/.ssh/google_compute_engine

Now, you can simply SSH using:

ssh nickname

Note that the path on Linux and Mac is ~/.ssh while the path on Windows is something like C:\Users\<user>\.ssh

GoTrained
  • 158
  • 1
  • 7
0

Re: #1: There's no flag on the command to change this behavior on a per-command level instead of a per-instance level ('block-project-ssh-keys', as you mentioned) but you could file a FR at https://issuetracker.google.com/savedsearches/559662.

Kristen Tracey
  • 152
  • 2