3

I have noticed in my GCE cluster that when I add an SSH key to the project metadata that it is then automatically added to /home/[user]/.ssh/authorized_keys. This is the behaviour I expect (and desire for the task I am doing at the moment). However, one of my machines in the cluster is not having it's authorized_keys file updated at all, whether I remove or add keys to the project metadata. I have even tried removing the authorized_keys file completely to see if it will be recreated (it isn't).

All the servers are up-to-date Ubuntu 14.04, and as far as I can tell it's only this one instance that has the issue. It is the 'oldest' instance in the cluster, so when reading https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#addkey I wondered if it was subject to the following statement:

If your instance does not support the newer metadata values, add or remove the older instance-only sshKeys value that applies your key only to a specific instance and also blocks all project-wide keys when the value is set.

But I have removed instance only sshKeys and the problem persists. Any ideas before I destroy & recreate the image to make sure I am able to use the 'new' metadata?

sheepeatingtaz
  • 131
  • 2
  • On GCE instance user account and ssh keys are synced with metadata server using [google-daemons](https://github.com/GoogleCloudPlatform/compute-image-packages#daemons) (account-manager). As such, you need to make sure account-manager script is running on your instance all the time in order for the keys to propagate. – Faizan Jun 21 '16 at 17:15

2 Answers2

3

First, make sure that your VM instance can communicate with metadata server and can read the project-wide sshKeys value. To verify this, connect to your VM and run the following command:

curl http://metadata.google.internal/computeMetadata/v1/project/attributes/sshKeys -H "Metadata-Flavor: Google"

The output of the command should be SSH keys that you've added to the metadata of your project. If the command can not communicate with metadata, that means your internal firewall blocks the traffic between your VM and metadata server.

If the communication is successful and you can read the value of sshKeys, then you should verify that account manager daemon is running. In Ubuntu 14.04, the daemon script is located at:

/usr/share/google/google_daemon/manage_accounts.py

Use the following command to verify its running status:

sudo ps aux | grep manage_accounts.py
Kamran
  • 1,425
  • 7
  • 17
  • 's answer did the trick but since they posted it the URL has changed. It's now; curl http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys -H "Metadata-Flavor: Google" – James Feb 05 '20 at 22:10
  • 1
    seems like it changed again – John White Jul 05 '21 at 11:34
0

In my case it was because I was looking at the wrong account. The account name is autogenerated from the last part of the SSH key, make sure to look in all home folders to see where it's installed.

John White
  • 236
  • 1
  • 3
  • 10