SSH to Docker container and run X11 on Mac Pro Host Machine

 So, I have an CoMA3 X11 app.  It is a genetic analysis pipeline.  I can run its Docker container on MAC OS like so:

docker run -it -e DISPLAY=$IP:0 -e XAUTHORITY=/.Xauthority --net=host --ipc=host -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/.Xauthority:/.Xauthority -v $(pwd):/home sebh87/coma3 bash

 Actually, I have to change it to this:

docker run -it -e DISPLAY=host.docker.internal:0 -e XAUTHORITY=/.Xauthority --net=host --ipc=host -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/.Xauthority:/.Xauthority -v $(pwd):/home sebh87/coma3 bash

but before running it I have to do this xhost + localhost.

It is not too bad since I am using .Xauthority's magic cookie for authentication.  The communication between my X11 client and server is over plan text so not so good.  I would like to run this over ssh instead.  So, I edited the original Dockerfile to this:

FROM sebh87/coma3:latest

RUN apt update && apt install  openssh-server sudo -y

RUN useradd -rm -d /home/ubuntu -s /bin/bash -g root -G sudo -u 1000 test 

RUN  echo 'test:test' | chpasswd

RUN service ssh start

EXPOSE 22

RUN apt install net-tools iputils-ping sudo -y

WORKDIR /usr/local/Pipeline/lotus2/usearch

RUN wget https://drive5.com/downloads/usearch11.0.667_i86linux32.gz

RUN gunzip *

RUN mv * usearch

RUN chmod 111 *

WORKDIR /usr/local/Pipeline

RUN mkdir projects

WORKDIR /usr/local/Pipeline/projects

RUN mkdir sample_data && cd sample_data && wget https://www2.uibk.ac.at/downloads/CoMA/CoMA_Tutorial.tar.gz && tar -xzf CoMA_Tutorial.tar.gz

WORKDIR /home

# adjust OpenSSH config

RUN echo "PermitUserEnvironment yes" >> /etc/ssh/sshd_config && \

  echo "X11Forwarding yes" >> /etc/ssh/sshd_config && \

  echo "X11UseLocalhost no" >> /etc/ssh/sshd_config

CMD ["/usr/sbin/sshd","-D"]

After that, I can do xhost - to block X11 connections all together.

So, now I can run docker like this:

docker run -p 2022:22 -d --rm -v $(pwd):/home private/coma3v7:latest

Note that I am mapping port 2022 because MAC host already has use for this port.

ssh -p 2022 test@0.0.0.0 

test@0.0.0.0's password: 

Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.10.124-linuxkit x86_64)

 * Documentation:  https://help.ubuntu.com

 * Management:     https://landscape.canonical.com

 * Support:        https://ubuntu.com/advantage

This system has been minimized by removing packages and content that are

not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

Last login: Fri Oct  7 03:09:25 2022 from 172.17.0.1

To run a command as administrator (user "root"), use "sudo <command>".

See "man sudo_root" for details.

test@bd3c4d0ffcb3:~$ env

_=/usr/bin/env

SSH_TTY=/dev/pts/0

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

SSH_CLIENT=172.17.0.1 64062 22

SHLVL=1

USER=test

TERM=xterm-256color

SSH_CONNECTION=172.17.0.1 64062 172.17.0.2 22

LANG=C.UTF-8

HOME=/home/ubuntu

MOTD_SHOWN=pam

TZ=Europe/Vienna

LOGNAME=test

PWD=/home/ubuntu

SHELL=/bin/bash

test@bd3c4d0ffcb3:~$ xeyes

Error: Can't open display: 

test@bd3c4d0ffcb3:~$ export DISPLAY=host.docker.internal:0

test@bd3c4d0ffcb3:~$ xeyes

That seems to work fine with a few security problems one being the password is in the Dockerfile.  Also the DISPLAY env var is set manually.  I guess this can be part of the Dockerfile as well and the SSH key can be saved in Docker secret and mount to the container at runtime.

If this is ran on a Linux instead of a Mac, things might be a little bit better because Docker behavior is a little different on Mac than it is on Linux host system.  I think Mac has a VM on it to make Docker work.  There is an extra layer of indirection I believe.  Could be wrong but I don't have enough interest to look deeper.

The advantage of no rely on "docker run" start the X11 session with ssh, I could reach the container app from anywhere routable.  The annoyance with the DISPLAY env var might be solvable with a little bit digging. 

Correction: xhost + <X server host name> still required.