Connecting to containers and VMs

Connecting to containers and VMs=

SSH, triton-docker exec, and Microsoft Remote Desktop are all supported connection methods to "log in" to instances in Triton.

Detailed instructions

SSH is the primary means of connecting and authenticating for command line access to all container types with the exception of Docker and Windows instances.

• SSH to an instance from Mac OS X or Windows

• Connecting to Docker containers using triton-docker exec

SSH key management

The propagation of SSH keys is handled differently depending on container type. The following table provides an overview of the differences.

Container Type	Authentication Type	Notes
SmartOS	Uses SmartLogin	Authenticates against current list of keys in the account of the container owner.
Container Native Linux	Uses authorized_keys file	Keys in the account of the container owner are copied at provision time. Changes to the keys in the account are not reflected. Can force an update to the authorized_keys file via a metadata item.
Hardware Virtualized Linux	Uses authorized_keys file	Keys in the account of the container owner are copied at provision time. Changes to the keys in the account are not reflected. Can force an update to the authorized_keys file via a metadata item.
Hardware Virtualized Windows	Uses generated administrator password	Uses password generated for a given account via the *generate_passwords" option in the image configuration json.
Docker Containers	Communication is via TLS secured HTTP; no sshd by default	Uses client certificate.

Notes:

• All access should be done as the root user unless otherwise noted.

• Newer Ubuntu distributions use the ubuntu user for remote access.

• Windows based distributions use the administrator account and the normal windows login process; Windows containers do not use SSH keys.