chorrell
commented
8 years ago The problem with having authorized_keys written to at each boot is that it could overwrite any ssh keys a user could have manually added. For the KVM Linux machines and the lx-brand linux machines, we only fetch the value of authorized_keys at first boot because of this. The SmartOS instances work differently since they have live ssh-key updating via SmartLogin (see https://docs.joyent.com/public-cloud/instances/connecting#ssh-key-management). At some point we'd like to offer a similar SmartLogin service for the lx-brand images.
Also, that doc link is a bit outdated. This is probably the most relevant one:
Line 73 in mdata-fetch tests whether /root/.ssh/authorized_keys exists. If the file doesn't exist, the root_authorized_keys metadata is fetched and placed into /root/.ssh/authorized_keys.new.
This means that when the machine metadata is updated, the authorized_keys file will not get updated -- since it already exists. The documentation for the Metadata API (https://docs.joyent.com/sdc6/api-documentation/using-the-metadata-api) indicates, however, that the authorized_keys file should be updated on reboot.
The script after line 73 indicates that there was consideration for updating the authorized_keys or removing them, depending on what was retrieved from the metadata store. I would expect the behavior should be consistent with the Metadata API documentation and the intent of the logic after line 73. I suggest re-evaluating whether line 73 should test for /root/.ssh/authorized_keys alone.
Utilizing Debian container image 1adf7176-8679-11e5-9ff7-3beedf8060b9, generated dated 20151109.