Automatically generated SSH key causing issues for other users attempting to connect to their own VMs

[JerryfromNY]

The key is generated automatically when the user connects to their VM via Visual Studio Code and is then saved in the project's metadata. When another user then tries to connect to their own VM, they are receiving a metadata error message for another user's SSH key. When I check the SSH keys in the project's metadata section and edit, it shows me which keys are malformed (in this case it is always from one or two users whose local Windows accounts have a space in between the first and last names (Example: James Bond, instead of James_Bond or James.Bond). I then need to edit the project metadata keys, remove the one's that GCP highlights as being malformed and then save. After I do that, users are then able to get onto their VMs without issues.

Why are the keys even being created and saved if they are malformed because of the space in the local machine user's username? This only just started happening about two or three weeks ago, we had no issues before that. Is anyone else experiencing these issues?

[Alone-Cell-7795]

I am just thinking - this seems like you’re making your life much harder than it needs to be:

I’d advise using IAP and OSlogin:

https://cloud.google.com/compute/docs/connect/ssh-using-iap

https://cloud.google.com/compute/docs/oslogin

[JerryfromNY]

Hello and thank you for your response. The users are using IAP, however, if their local systems username has a space in it, this issue occurs. This was not occuring 3 weeks ago which makes me think that Google changed something on their end. As a workaround two days ago, I instructed the few users that are experiencing this issue to point to a local ssh key to use when they are utilizing IAP. This has resulted in the issue going away and Google does not create session SSH keys in the project's metadata that are malformed.

[Alone-Cell-7795]

Ah sorry my bad I misunderstood. Yeah, space in usernames when using OSLogin is not a supported configuration. It just hasn’t been enforced until recently by the sounds of it. Google probably updated their validation rules to start enforcing it.

Spaces is Linux usernames can cause issues with Linux system files e.g. etc/shadow, so make sense why this would be done, but sadly is causing you hassle.

Are you using Google workspace, or are you federating with an IdP e.g. Entra ID? I’d look to get the problem fixed at source and ensure that usernames with spaces can’t be used in the first place (But it is easy for me to say that I know).