packer does not support google oslogin

[Tahvok]

Using packer version: 1.4.1

If you bring up your instances with oslogin enabled packer is unable to connect to them. Even if ssh-agent is present with correct key and correct ssh_username is supplied.
Basically to test this, when packer has created the instance I was able to connect from the same source instance via ssh, but packer still couldn't. I would expect packer to at least try to use the running ssh agent.

Log:
https://gist.github.com/Tahvok/9325ab2961fb0bf9b8e89e70fa3b32a0

Builder to reproduce:

"builders": [
        {
            "type": "googlecompute",
            "project_id": "project-id",
            "zone": "us-central1-a",
            "instance_name": "coreos-stable-2079-4-0-v20190515",
            "source_image": "coreos-stable-2079-4-0-v20190515",
            "ssh_username": "service-account-username",
            "image_name": "image-name",
            "metadata": {
              "enable-oslogin": "TRUE"
            }
        }
    ]

[azr]

Hello @Tahvok, thanks for opening. Weird, it worked for me using :

            "machine_type": "n1-standard-1",
            "source_image": "debian-7-wheezy-v20150127",
            "ssh_username": "packer",
            "type": "googlecompute",
            "zone": "{{ user `zone`}}",
            "metadata": {
              "enable-oslogin": "TRUE"
            }

EDIT: I could repro with core os.

[azr]

But now this looks like to me it is a bug with the os / or cloud provider and not packer 🤔

[Tahvok]

Have you completely enabled oslogin on google?
https://cloud.google.com/compute/docs/instances/managing-instance-access

I have found issue #6341 where it didn't work for @rosstimson as well, and he had to workaround it by setting enable-oslogin to false in metadata

[azr]

I have enabled it just for the individual instance :

1. Enable the OS Login feature on your project or on individual instances.

[rhencke]

I believe this is a bug/missing feature in the Google Cloud provider.

There are two ways I am aware of for managing SSH key access with GCP:

• SSH metadata
• OS Login

From what I can tell through reading https://github.com/hashicorp/packer/blob/78c0b7bd9c1c2464c407fadbed3da4e94e627796/builder/googlecompute/step_create_instance.go it seems that the cloud provider currently only handles SSH metadata-based key access, and doesn't appear to support OS Login.

[rickard-von-essen]

@rhencke pretty sure everything is there o the GCP side, someone just need to take some tune and investigate exactly how this should be done and implement the support. I expect it to be fairly straightforward do.

[thnee]

Can confirm, this is still a problem. I used to have OS Login disabled, and packer was working fine. Then I enabled OS Login on the project level, and packer stopped working with this output.

==> googlecompute: Waiting for SSH to become available...
==> googlecompute: Error waiting for SSH: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
==> googlecompute: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
==> googlecompute: Step "StepConnect" failed

Fortunately, the workaround is simple, just add this to the googlecompute builder in the packer file.

  "metadata": {
    "enable-oslogin": "FALSE"
  }

[dvmorris]

Is there a plan to support this in the future? I just ran into the same issue today.

[SwampDragons]

We're not actively working on this, yet, but PRs are always welcome. :)

[kevinbirch]

We're not actively working on this, yet, but PRs are always welcome. :)

Could you roughly estimate the level of effort for someone outside Hashicorp to implement this feature?

[SwampDragons]

Well, with one major caveat: I haven't researched how OSlogin works or how to link it to Packer, so that element could be totally simple through the SDK, or downright impossible. But assuming it's doable via the google sdk for go, this shouldn't be too hard to implement. (famous last words). You can get an idea of how the current authentication is handled by tracing the AccountFile through the code: https://github.com/hashicorp/packer/blob/master/builder/googlecompute/config.go#L36

That gets a little hairy when it calls out to the oauth code, but you don't have to follow it all the way through to see how Packer handles it on input. It's possible oslogin could be simpler; you'd add a feature to that config struct like use_oslogin or something, and call out to the sdk in the Prepare() instead of doing the AccountFile prep in that same Prepare method.

[cpwc]

Tested out using OSLogin for service accounts, here are some of my findings.

SSH key generated or provided have to be added to gcloud account using this command.

gcloud compute os-login ssh-keys add --key-file [path-to-pub-file]

Once the command completes it will return some information below. The information can determine the ssh_username to be used for communicator.

loginProfile:
  name:  [redacted]
  posixAccounts:
  - accountId: [redacted]
    username: [SSH_USERNAME]
  sshPublicKeys:
    [redacted]

Depends if you are logging packer as a service_account or user the ssh_username to be used will differ.

Note: If role given is Compute OS Admin Login you will be logged in directly as a user with administrative rights.

Couple of thoughts on how we could potentially implement support for OSLogin.

• Check for specific config to enable the use of OSLogin?
• Before/after we create the instance add the SSH key using the command above. There are APIs available for that as well https://cloud.google.com/compute/docs/oslogin/rest
• Replace the ssh_username to be used with the one returned from OSLogin.
• Proceed as per normal for SSH communicator.

[cpwc]

Would like to get some help in obtaining user's email if user is not using account.json file and it will fallback to default credentials. As per the API one of the parameter parent needs to be of a specific format users/{user} which will be user's email address in this case.

Almost there for a PR to add support for this, just need to get this sorted.

@SwampDragons

https://github.com/googleapis/google-api-go-client/blob/v0.25.0/oslogin/v1/oslogin-gen.go#L680

[thnee]

@cpwc When using Ansible, I rely on gcloud compute os-login describe-profile to get the needed information about the user.

[cpwc]

@thnee yeah. Unfortunately there's no API that could do just that. There's this https://cloud.google.com/compute/docs/oslogin/rest/v1/users/getLoginProfile API but it still require to know the user's email before hand to craft the API request.

[cpwc]

👋 hello would love to get some inputs from those who are looking for oslogin support on packer. Would like you guys to test out the binaries from #9469 and see if it's how you would expect oslogin to work based on the work and help from @nywilken

[eriksw]

@cpwc To find the email of the default google credentials, see oauth2/Service.TokenInfo.

Instantiate the Service without configuring credentials in any way, then call that and check the Email in the result struct.

---

For my use case, I would like to have packer use a service account (running within CI) to log into the instance being built.

My expectation for oslogin support in packer would be for it to "just work" exactly the same as if packer was shelling out to gcloud compute ssh ... --tunnel-through-iap. In particular, I do not ever want to have to create, store, or manage the lifecycle of an ssh key—I would expect packer to keep the fact that there is an ssh key involved a fully-ignorable implementation detail just the same as gcloud compute ssh does.

[nywilken]

@eriksw thanks for pointing out oauth2/Service.TokenInfo. We will take a look.

My expectation for oslogin support in packer would be for it to "just work" exactly the same as if packer was shelling out to gcloud compute ssh ... --tunnel-through-iap. In particular, I do not ever want to have to create, store, or manage the lifecycle of an ssh key—I would expect packer to keep the fact that there is an ssh key involved a fully-ignorable implementation detail just the same as gcloud compute ssh does.

For this scenario would you specify the correct username in the case of a service account something like sa_123456789987654567890987654? Or would you expect Packer to figure that out as well?

I think this is what you are alluding to already, but seeing as OSLogin usernames must be specific to an account I want to make sure that dynamically updating the username would be an expected behavior. This is in regards to "Replace the ssh_username to be used with the one returned from OSLogin." mentioned in @cpwc investigation

An alternative could be that Packer errors if the username doesn't match the username provided by OSLogin to avoid surprises.

[eriksw]

I would strongly prefer to not have to set ssh_username at all when using oslogin.

Having packer correctly determine the username in use the same way gcloud compute ssh does would make the same template usable without modifications by both a user who has access to the project and also service account CI.

[nywilken]

@eriksw thanks again for the tip on oauth2/Service.Tokeninfo. I went ahead and added a few changes on top of the awesome work done by @cpwc to handle the dynamic SSH key importing for service accounts. Would you mind giving it a try?

The test binaries can be found here. Documentation for the use_os_login option can be found here

[nywilken]

Hello again, support for OSLogin has been merged and will be available in the v1.6.1 Packer release. If you would like to gain access to this feature before its official release it will be available for use in the next nightly release. There are also test binaries here if you would like to give the feature a try. Cheers!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.