Bottlerocket images do not have an SSH server nor even a shell. As it turns out, you don’t need one in the host operating system itself. Bottlerocket does, however, give you out-of-band access that allows you to launch a shell from a container to explore, debug, manually update, and change settings on the host.
Since the software doesn’t exist on the host to facilitate interactive shell sessions, it is provided through a container. These containers are granted access to resources on the underlying host, have the required software for remote connections, and are run in the host containerd instance.
The control container’s purpose is to provide a first-tier host access where you can make API calls and gain access to some host-level resources.
aws-ecs-* variants, the control container is on by default and remote connections are made through AWS SSM.
The control container is also the path to enable or enter the admin container.
The admin container is designed to provide out-of-band access with elevated privileges.
aws-ecs-* variants, the admin container is not enabled by default but can be turned on or entered through the control container.
The best security practice is to disable the admin container and only enable it as-needed.
The admin container has a mount to the host file system1, an unrestricted SELinux label as well as all of the capabilities of the control container. Using the admin container should be rare: only used as-needed and by those required.
For variants designed to be used with Kubernetes, you can gain out-of-band access to a node by using
kubectl exec and a pod spec with specific volume mounts and security contexts.
You can read more about this method in Regaining Access to a Bottlerocket Node.
This method is very similar to running the control container, but it runs in the orchestrated containerd instance instead of the host containerd instance.