# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mnx.io/instances/connecting-to-containers-and-vms.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.