Wrong SSH username on GCE

[DerrickMartinez]

/kind bug

1. What kops version are you running? The command kops version, will display
this information.

v1.29.0

2. What Kubernetes version are you running? kubectl version will print the
version if a cluster is running or provide the Kubernetes version specified as
a kops flag.

1.29.5

3. What cloud provider are you using?

GCP

4. What commands did you run? What is the simplest way to reproduce this issue?

After an instance is in service you cannot SSH. The SSH username is set to admin, not ubuntu.

- key: ssh-keys
  value: 'admin: ssh-rsa AAAAB3NzaC1yc2blah... ubuntu@localhost'

Here is a valid, working instance template that it should look like

- key: ssh-keys
  value: ubuntu:ssh-rsa AAAAB3NzaC1yc2blah... ubuntu@localhost

It looks like fi.SecretNameSSHPrimary is a const of admin

pkg/model/gcemodel/autoscalinggroup.go: gFmtKeys = append(gFmtKeys, fmt.Sprintf("%s: %s", fi.SecretNameSSHPrimary, key))

I would be willing to submit a PR depending on how we want to fix this.

[hakman]

@DerrickMartinez what image are you using for your instances and what is the cluster creation command?

[VitusAcabado]

Hi I am experiencing the same issue. Image I am using for my instance groups is: ubuntu-os-cloud/ubuntu-2204-jammy-v20240904

If I add a global public key to GCP metadata it works, however since kops instance group sets the username as admin, key will not work if I disable the global public key.

this works as gcp infers that the username should be ubuntu:

public key added by kops does not as username set is admin:

I am using kops client version 1.30.0 and kubernetes version of 1.27.7

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten