> For the complete documentation index, see [llms.txt](https://docs.mnx.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mnx.io/instances/connecting-to-containers-and-vms.md).

# 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](/instances/connecting-to-containers-and-vms.md#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](/getting-started/ssh-from-windows.md)
* Connecting to Docker containers using `triton-docker exec`

### [SSH key management](/instances/connecting-to-containers-and-vms.md#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.