SmartLogin only works with SmartOS zones. Control of key-based access to bhyve, kvm, and lx isntances can be accomplished using OpenSSH's authorized keys command to fetch authorized keys from the metadata service.
The guest OS needs to have the following added to {{/etc/ssh/sshd_config}}.
AuthorizedKeysCommand /usr/sbin/mdata-get "%u_authorized_keys"
AuthorizedKeysCommandUser mdataget
The mdataget user needs to exist and have read-write access to /dev/ttyS1. For example, on CentOS, /dev/ttyS1 is writeable by the dialout group. Creating the mdataget user with group dialout accomplishes the goal of having a limited privilege user that can retrieve public keys.
# ls -l /dev/ttyS1
crw-rw----. 1 root dialout 4, 65 Jul 26 21:03 /dev/ttyS1
# useradd -g dialout -rlM -s /sbin/nologin -d / mdataget
After making these modifications, restart the SSH service:
# systemctl restart sshd.service
Assuming no sshd_config modifications were made other than those described above, users will be able to log in if $HOME/.ssh/authorized_keys in the file system or <user>_authorized_keys exists in the the metadata service. <user>_authorized_keys may be maintained using mdata-put, CloudAPI, Portal, AdminUI, or vmadm update. Not all methods are able to modify root_authorized_keys.
Because updates to root_authorized_keys in customer_metadata are somewhat restricted, it may be difficult to update and audit the keys that grant root access. Additionally, many security experts recommend against logging in directly as root. To disable root access via ssh, ensure the following is in /etc/ssh/sshd_config:
PermitRootLogin no
It is also a good idea to remove root_authorized_keys as these are not updated when the Triton account's ssh keys are rotated. Be sure this is done only after ensuring another user can access the VM and root access can be obtained using that account.
root@instance# mdata-delete root_authorized_keys
In some use cases, it may be desirable to disallow the use of $HOME/.ssh/authorized_keys to prevent users that gain shell access via <user>_authorized_keys from adding unsactioned keys. To do so, ensure a single authorized keys file configuration line exists in /etc/ssh/sshd_config as:
AuthorizedKeysFile none
As always, the SSH service needs to be restarted after modifying sshd_config.
There are some things about this that are not great and may be improved over time.
mdata-get retrieves data over a serial port, takes 100 ms or more per key. Only one process may access the serial port at a time, which serves as a significant throttle to the potential login rate. While this may not be an issue for normal use, an attacker could use it to reduce the likelihood that an authorized user could gain timely access.
To imrove this, mdata-get could gain the ability to cache results and return cached results that are significantly recent. Even if cached results are valid for only few seconds, it would mitigate the aforementioned attack vector for systems with relatively few accounts.
Portal and perhaps other commands or APIs are limited in their ability to update root_authorized_keys. This restriction should be relaxed.
It would be very helpful for updates to the Triton account's SSH keys to trigger matching updates to each instance's root_authorized_keys metadata.