sudo access depends upon SSH key registration with OS Login

[tpdownes]

Customers report the following observed sudo behavior of VMs when OS Login is enabled is as follows:

1. If the user logs in with a key registered in OS Login (most typically via gcloud compute ssh) and the user has roles/compute.osAdminLogin, then the AuthorizedKeysCommand / google_authorized_keys binary adds a per-user sudoers file to /var/google-sudoers.d/ and the user is able to run sudo.
2. If the user subsequently logs in with a key not registered in OS Login, but has been manually added to the user's authorized_keys file, then they may retain sudo access from step 1 for a period of hours, but it is eventually lost and they must repeat Step 1.

If Step 2 is accurate, then this is probably being reset by OS Login cache systemd timer. Perhaps VMs are rebooting without their awareness? I'd like some insight if you have any.

Step 2 is common enough in clusters of VMs with shared filesystems, especially when user /home directories are shared for purposes of large-scale workloads. Could sudo escalation occur by a PAM-based mechanism rather than set by sshd at initial authentication? I see this mentioned in the README:

*   **PAM Modules** which provide authorization (and authentication if
    two-factor support is enabled) support allowing the system to use Google
    Cloud IAM permissions to control the ability to log into an instance or to
    perform operations as root (via `sudo`).

but I was not able to find the file pam_oslogin_login.so anywhere within the OS. We have been using recent copies of the guest-oslogin package. If you need a specific version for reproduction purposes, please let me know. I believe the gap in PAM may be a known issue.