Saltar al contenido principal
El panel de containers tiene un selector de objetivo: Local o el alias de cualquier host SSH registrado. Es el buen caso de uso de todo esto: estás en una sesión SSH en un host, abres el panel, y ya está listando los containers de allá.

​
El objetivo se infiere del workspace

Casi nunca necesitas tocar el selector. Si el workspace activo es una sesión SSH, el panel ya abre apuntando a ese host.
Workspace local, objetivo Local. Workspace de un host, ese host como objetivo. El selector está ahí para cuando quieras salir del valor por defecto.

​
Cómo funciona por debajo

docker habla con una máquina remota de forma nativa, por ssh://. TYBA solo apunta el objetivo:
Y esto funciona porque el alias resuelve: TYBA ya escribió el Include config.d/tyba.conf en tu ~/.ssh/config. El alias que registraste es un host de verdad para OpenSSH, así que es un host de verdad para Docker. Nada de daemon expuesto, nada de puerto abierto, nada de TLS que configurar. Es tu SSH.

​
El shell de un container remoto

Abrir el shell de un container remoto crea un workspace propio, con el alias en el título y el color del host. Eso es a propósito: no secuestra tu pane SSH. Mezclar los dos dejaría el sh: postgres de esta máquina con la misma cara que el que corre en el host remoto, y confundirlos sale caro.

​
Las limitaciones

Un host solo-contraseña no funciona. El Docker remoto exige clave.El helper de Docker llama a ssh con el stdin nulo — no hay dónde aparezca el prompt de contraseña, ni quién lo responda. El caso no da un error claro: cae en el timeout.Forzar BatchMode daría un mensaje mejor, pero rompería tu sesión interactiva. Entonces: registra una Private key (path) en el host, y el panel remoto funciona.
El compose no corre en el objetivo remoto. Up, down, restart, abrir la carpeta del proyecto y abrir el archivo compose quedan deshabilitados cuando el objetivo es un host SSH.El motivo: esas acciones dependen de rutas del proyecto en esta máquina, y la ruta del host remoto no existe aquí. Para compose remoto, usa un pane SSH y corre docker compose allá.
Lo que sí funciona remotamente: listar, logs, shell y remover.

​
Es más lento — y está bien

El refresh remoto paga handshake, red y, en la primera conexión, lo que tu autenticación SSH exija — escribir la passphrase de la clave, tocar la YubiKey, aprobar en el agent. El timeout local mide un Docker que responde en milisegundos; el remoto gana bastante más holgura, porque con el techo local el panel remoto solo entregaba una lista vacía. Después de la primera conexión, el ControlMaster reusa la conexión y las llamadas vuelven a ser rápidas.
La disponibilidad se cachea por objetivo. Docker en esta máquina no dice nada sobre Docker en un host remoto, así que cada objetivo tiene su propio estado — y el panel no se queda repreguntando cada vez que le echas un ojo.
Esto vale para Windows también: sin ControlMaster, cada llamada del panel remoto puede reabrir la conexión y volver a pedir autenticación.

​
Ver también

Containers

El panel, la integración y lo que hace en local.

Hosts y grupos

El registro, la clave y el Include que hacen que esto funcione.