# 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](#detailed-instructions) <a href="#detailed-instructions" id="detailed-instructions"></a>

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](https://docs.mnx.io/getting-started/ssh-from-windows)
* Connecting to Docker containers using `triton-docker exec`

### [SSH key management](#ssh-key-management) <a href="#ssh-key-management" id="ssh-key-management"></a>

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.