Ssh x11 forwarding windows

Картинка с сайта: habr.com

Разве что ленивый не писал про ssh и несмотря на это, данный протокол и его возможности не перестают меня восхищать. Здесь я хочу поделиться исключительно своим опытом использования сего замечательного инструмента в своих задачах (При этом активно применяю его даже при разработке на Windows).

Поскольку я программист, то инструментарий ssh часто нужен мне в разработке и для личных нужд. Самые частые задачи, которые я выполняю с его помощью (по частоте использования):

• Удалённый доступ — логично, ведь для этого он и предназначался.
• Монтирование папок по сети — очень удобно для работы с кодом на удалённой машине.
• Удалённое выполнение команд — нечастая, но используемая мной операция. Удобно получать выхлоп команды в канал другой команды на текущей машине.
• Запуск графических приложений на удалённой машине.
• Проксирование трафика — способ перенаправления трафика. Этакий быстрый и простой аналог VPN.
• Обратный ssh — использую для проброса портов к системам, находящимися за NAT, когда лень настраивать firewall.

Далее вкратце разберу каждый пункт, и особенно пути эффективного и простого использования под Windows.

Конфигурирование рабочей машины

Забавно, что в различных примерах использования ssh, этот важнейший момент обходят стороной, хотя, как по мне — он ключевой. Приведу вполне живой пример, того, как я делаю первичную настройку сервера под себя.

После того как я выбрал и заказал себе сервер VPS, у меня в панели создания сервера появляется логин и пароль, и как это не удивительно — логин root.

Картинка с сайта: habr.com

Результат создания сервера

Первое, что нужно сделать прямо сразу после создания сервера: отключить логин по руту, настроить фаервол и проковырять в нём дырочку для корректной работы ssh. В идеале отключить логин по паролю и оставить только логин по ключу.

Когда-то я уже делал хороший гайд в наш Справочник о первичной настройке Ubuntu 18.04. Вся информация актуальна и применима к Ubuntu 20.04. Подробно расписывать, что я делаю — не буду, но дам небольшие пояснения.

ssh remotehost #заранее прописал ip сервера в /etc/hosts
adduser dlinyj #добавляем нового пользователя
usermod -aG sudo dlinyj #добавляем пользователя в группу sudo

Обращаю внимание, что я создаю пользователя такого же, как и на локальной машине, и поэтому — далее по тексту его не указываю. Если у вас пользователь отличается от того, что на сервере, то логиниться нужно через user@remotehost.

Далее необходимо отключить логин пользователя root. Это очень важно, потому что, в конце концов, методом перебора сервер рано или поздно будет взломан.

nano /etc/ssh/sshd_config

Находим строчку, содержащую PermitRootLogin, и меняем её на состояние no.

PermitRootLogin no

После этого перезапускаем ssh-сервис.

service sshd reload

Обязательно рекомендую проверить, что вы больше не можете зайти под рутом с тем же паролем, и эти изменения успешно применились.

После чего проверяю успешность подключения от своего аккаунта dlinyj, и затем копирую ключи. Логин по ключам имеет две цели: не вводить пароль каждый раз вручную, и просто отключить логин по паролю. Ключи перебрать значительно сложнее, чем пароль по словарям. Главное — не забыть сгенерировать пару ключей командой ssh-keygen. Можно сделать сложные ключи, а можно более простые. Тут уж дело вкуса, а я особо не заморачиваюсь и просто запускаю данную команду.

ssh-keygen

После успешной генерации пары ключей: публичного и приватного, копируем публичный ключ с помощью следующей команды:

ssh-copy-id remotehost

Проверяем логин. Введя ssh remotehost — мы должны сразу зайти на удалённый сервер с текущим логином.

После чего можно и вовсе отключить логин по паролю. Если вы единолично используете сервер, то это лучший вариант. Меня пугает ситуация, что если я потеряю приватный ключ, то попасть на сервер будет проблематично, но не сказать об этом нельзя.

Снова редактируем файл:

sudo nano /etc/ssh/sshd_config

Находим строку PasswordAuthentication, раскомментируем её и ставим no. Всё, перезапускаем ssh сервис командой sudo service sshd reload и наслаждаемся жизнью. Также настоятельно рекомендую настроить фаервол, согласно мануалу.

В заключении главы хочу порекомендовать внимательно посмотреть на все возможные настройки sshd, которые кроются в конфигурационном файле. Можно ограничить время сессии, количество подключений и многое другое.

Мои основные применения ssh

Итак, пробегусь по основным применениям ssh, кроме банального удалённого доступа.

▍ Удалённое выполнение команд

Простейший пример — это выполнить и записать команду сразу после адреса удалённого хоста.

Например:

ssh remotehost cat /etc/passwd | grep dlinyj

Вернётся следующая строка:

dlinyj:x:1000:1000:,,,:/home/dlinyj:/bin/bash

Обратите внимание, что grep выполнился уже на стороне машины, с которой мы делали запрос. Это можно увидеть, если добавить вывод, например, ip-адреса:

ssh remotehost cat /etc/passwd | grep dlinyj;ip a
dlinyj:x:1000:1000:,,,:/home/dlinyj:/bin/bash
...
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.**.**/24 brd 192.168.**.** scope global dynamic noprefixroute enp6s0
       valid_lft 378sec preferred_lft 378sec
...

Если мы хотим, чтобы цепочка команд была выполнена на стороне хоста, то следует брать команды в кавычки.

ssh remotehost "cat /etc/passwd | grep dlinyj;ip a"
dlinyj:x:1000:1000:,,,:/home/dlinyj:/bin/bash
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** scope global eth0
       valid_lft forever preferred_lft forever

При этом бывает удобно использовать как первый, так и второй вариант. При первом варианте удобно получать выхлоп в свои скрипты, а при втором — делать что-то большое на удалённом сервере.

▍ Копирование файлов «на» и «с» удалённого хоста

В линуксе достаточно банальная операция копирования по протоколу scp, которая осуществляется с помощью команды scp. Данная программа используется точно так же, как и команда cp, с той особенностью, что надо указывать адрес удалённого сервера. Пример использования:

$ touch testfile
$ scp testfile remotehost:~/
testfile                      100%    0     0.0KB/s   00:00    
$ ssh remotehost ls testfile
testfile

Здесь я создал файл, затем скопировал его на удалённый хост (в домашнюю папку), и после, проверил его существование. Аналогично можно копировать и в обратном направлении.

▍ Монтирование удалённых папок

Для меня это является чуть ли не самой часто используемой функцией. Даже научился через тернии использовать её в Windows. Монтирование папок с удалённого хоста чаще всего использую для разработки на удалённом сервере, особенно если он какой-то отличный от x86 архитектуры. Да, Visual Studio Code умеет работать по ssh, но мне этот функционал не понравился. Плюс, не на каждый удалённый хост можно поставить дополнительные пакеты, чтобы работало всё гладко и там был поиск по файлам внутри студии. Когда программа большая (например, исходники Android) — поиск по файлам бывает очень нужен.

Очень удобно работать с удалённой папкой локально, будто бы она находится здесь и сейчас. Единственное, чего мне не хватает в этом функционале — это корректная работа inotify для отслеживания изменений файлов на удалённой машине. С такими примонтированными папками можно творить потрясающие штуки. Например, я организовывал взаимодействие двух сервисов, данные которых обменивались через примонтированные по ssh каталоги. Единственное, что не удалось — отслеживать изменения файлов, выполненные удалённой машиной. Тут пришлось изобретать другие схемы синхронизации.

Для того чтобы монтировать удалённые папки, нужно установить приложение sshfs.

sudo apt install sshfs

Теперь можно сделать монтирование удалённой папки. Для этого нужно указать локальную точку монтирования и путь к удалённой папке. Например, смонтируем папку home удалённого сервера — в папку ~/home локальной машины:

mkdir ~/home
sshfs remotehost:/home/dlinyj/ ~/home

В том, что монтирование прошло успешно, можно убедиться командой mount:

mount
....
remotehost:/home/dlinyj/ on /home/dlinyj/home type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Убедимся, что папка не пуста:

ls -la ~/home/
итого 40
drwxr-xr-x  1 dlinyj dlinyj 4096 июл 11 23:49 .
drwxr-xr-x 28 dlinyj dlinyj 4096 июл 12 00:01 ..
-rw-------  1 dlinyj dlinyj  983 июл 11 23:46 .bash_history
-rw-r--r--  1 dlinyj dlinyj  220 июл 10 21:40 .bash_logout
-rw-r--r--  1 dlinyj dlinyj 3771 июл 10 21:40 .bashrc
drwx------  1 dlinyj dlinyj 4096 июл 10 21:44 .cache
drwxrwxr-x  1 dlinyj dlinyj 4096 июл 10 22:39 .local
-rw-r--r--  1 dlinyj dlinyj  807 июл 10 21:40 .profile
drwx------  1 dlinyj dlinyj 4096 июл 10 23:25 .ssh
-rw-r--r--  1 dlinyj dlinyj    0 июл 10 21:41 .sudo_as_admin_successful
-rw-------  1 dlinyj dlinyj   57 июл 11 23:49 .Xauthority

Это самый крутой инструмент ssh, который приводит меня в полнейший восторг. Если бы можно было монтировать под Windows удалённые папки из Linux-машин, то было бы просто великолепно. Хотя и это тоже возможно сделать без особых проблем.

▍ Запуск удалённых графических приложений

Это называется X11 Forwarding, и для того чтобы продемонстрировать данный функционал, необходимо настроить ssh-демон. Снова на удалённом сервере редактируем файл sshd_config:

nano /etc/ssh/sshd_config

Находим там строку X11Forwarding, раскомментируем её и ставим значение yes:

X11Forwarding yes

И после — не забываем перезапустить сервис sshd.

service sshd reload

Чтобы показать работу «проброски окошек» — нужно на чистый сервер без «иксов», установить хоть какие-нибудь X-приложения. Для этого я выполнил:

sudo apt install x11-apps

Это легковесный пример графических приложений, который для своей установки не требует много места. Отключаемся от удалённого сервера комбинацией клавиш ctrl-d (deattach) и подключаемся уже с опцией -X:

Картинка с сайта: habr.com

Глазки удалённого сервера следят за вашей мышкой

Как видно, графические приложения удалённого сервера прекрасно взаимодействуют с мышью.
Но к сожалению — не всё так радужно. Конечно, можно весь оконный менеджер так запустить, и оно будет работать, но будет дико тормозить. Обычно подобный запуск я использую исключительно для того, чтобы посмотреть какие-то графики, картинки, или глянуть последнюю вкладку в браузере на удалённом сервере. Последний раз, когда пробовал пробрасывать окошко логического анализатора — пользоваться этим было практически невозможно. Для полноценной работы всё же лучше использовать RDP.

▍ Проксирование трафика

Не могу сказать, что часто использую данный функционал, но несколько раз он меня выручал. Он особенно полезен, если нужно пропустить трафик через удалённый сервер, а морочиться с настройкой нормального VPN нет времени или желания. Этакий туннель для бедных.

Если посмотреть все мануалы про то, как проксировать трафик, то там приводится просто команда ssh, но совершенно не рассказывается о том, как настроить демона. При этом команда выполнится, но фокуса не произойдёт. Поэтому начну с главного — как разрешить проксирование. Для этого снова редактируем наш многострадальный файл конфигурирования демона ssh.

Находим там следующую строку, раскомментируем её и приводим к виду:

AllowTcpForwarding yes

Картинка с сайта: habr.com

Сохраняем файл и перезапускаем демон. После этого можно создать канал прокси к нашему серверу следующей командой:

ssh -D 8888 remoteserver

Где 8888 — локальный порт для прокси. Всё, теперь с данным прокси можно настроить и браузер. Пример настройки для firefox:

Картинка с сайта: habr.com

С хромом — ещё проще. Достаточно запустить его из командной строки:

google-chrome --proxy-server="socks5://localhost:8888

Если теперь перейти на сайт myip.ru, то там будет отображаться адрес вашего сервера:

Картинка с сайта: habr.com

Тут адрес вашего сервера

Таким образом, проксирование успешно работает. Отмечу, что это не такой уж и экзотический способ. Для смартфонов есть даже всякие приложения, которые умеют проксировать весь трафик мобильного устройства.

▍ Обратный ssh

Эта опция прям редко-редко мной использовалась, но были случаи, когда реально выручала. Суть такова — ваш домашний компьютер, либо какое другое устройство под управлением *nix находится за NAT и у вас нет выделенного IP. Есть множество решений этой проблемы, но, как по мне, идеальным решением будет обратный ssh. Со мной многие не согласятся и будут даже правы, но для меня это простой и понятный путь. Не агитирую.

Создаётся ssh соединение, по которому с удалённого сервера можно будет подключиться к вашему домашнему ПК. Итак, с домашнего ПК необходимо выполнить следующую инструкцию:

ssh -R 5544:localhost:22 remotehost

Опция R говорит перенаправлять порт удалённого хоста на указанный порт локального компьютера. Выполняем её и у нас будет поднято ssh-соединение до удалённого сервера. Если теперь подключиться к удалённому серверу, например, с работы, то можно получить доступ к домашней машине следующей командой:

ssh localhost -p 5544

Вжух, и вы на своей домашней машине, вне зависимости от того, где она находится.

Особенность в том, что на домашнем компе надо держать активную сессию и плюс — данные не сжимаются. Поэтому немного модифицируем инструкцию, чтобы всё работало быстрее.

ssh -fCNR 5544:localhost:22 remotehost

• -f выполняет команду ssh в фоновом режиме, однако, если закрыть окно терминала — сессия прервётся (используйте nohup),
• -C сжатие данных,
• -N не выполнять удалённые инструкции.

Если хочется, чтобы можно было подключиться извне, то нужно на удалённом хосте тоже сделать перенаправление портов. Делается следующей командой и выполняется на хосте:

ssh -fCNL *: 1234: localhost: 8888 localhost 

• -f Фон.
• -C Сжатие.
• -N Не выполнять инструкции.
• -L Перенаправляет порт на локальной машине (клиенте) на указанный порт, указанной удалённой машины.

Всё. Проковыриваете дырку в фаерволе для порта 1234 и из внешнего мира можно подключиться к вашему домашнему компьютеру, просто подключившись к remotehost по порту 1234.

Из недостатков способа можно отметить то, что сессия рвётся по таймауту, и если вдруг произошло отключение (плохой интернет), то связи больше не будет. Но специально для нас придумали autossh. Параметры такие же, как и у ssh, только он восстанавливает соединение после разрыва. Подробнее можно прочитать тут.

А как же Windows?

Ох, ОС Windows — это моя личная боль, при использовании ssh. Всем хороша операционная система, но плохо совместима с linux. На одной работе локальные компьютеры были под Windows, а разработка велась на удалённом сервере под Linux. При этом установить linux локально запрещала политика компании, как и ставить какой-либо иной софт, кроме разрешённого скромного списка. И эта личная боль (и опыт), решение которой я хочу изложить в этой части статьи.

Из широко распространённых инструментов можно отметить консольный клиент putty, который я использую для удалённого администрирования и WinSCP — для копирования файлов. С программой копирования по протоколу SCP всё более-менее понятно — это обычный командер. Единственное, что мне в ней не нравится, что если сессия рвётся по таймауту, то приходится заново создавать подключение, а это долго и раздражает. Да и в целом — я не нахожу её особо удобной, поэтому следует рассказать об альтернативных путях.

Картинка с сайта: habr.com

Копирование прошивки на малину.

Вот putty не так прост, как кажется на первый взгляд. Для меня эта программа — эталон удобства, и порой даже думаю поставить её под linux, хотя это и оверкилл. Программа позволяет делать практически все операции, описанные выше, кроме монтирования папок и копирования файлов: проксирование, проброс иксов, обратный ssh. Расскажу то, чем пользуюсь я (кроме банального удалённого доступа) — это проброс X11 на локальную машину.

▍ Проброс X11 в Windows

Поскольку Windows не имеет собственного Windows X-сервера, его следует предварительно установить. Есть несколько программ для этого. В своих решениях я использую VcXsrv Windows X Server. После установки запускаем и не забываем установить номер дисплея равный нулю:

Картинка с сайта: habr.com

Далее всё по умолчанию, разве что стоит отключить opengl:

Картинка с сайта: habr.com

Щёлкаем далее и готово.

В putty необходимо разрешить перенаправление иксов. В сессии, которую вы создали и сохранили для вашего удалённого сервера необходимо пойти в настройки, и найти вкладку X11, и там включить X11-перенаправление. В моём случае это выглядит так:

Картинка с сайта: habr.com

Всё, теперь можно посмотреть на глазки, следящие за курсором, но уже в Windows.

Картинка с сайта: habr.com

Глазки следят за курсором в Windows.

▍ Когда хочется POSIX в Windows

Конечно, всё это хорошо, но когда привыкаешь к магии и простоте консольных команд копирования, удалённого выполнения и прочего, то в Windows всего этого не хватает. Поэтому я долго искал какие-то более-менее вменяемые альтернативы. Главное — отказаться от WinSCP. Простейшей, и вполне удобной альтернативой оказался Cygwin. По сути, это коллекция инструментов GNU, которые обеспечивают функциональность, аналогично дистрибутиву Linux для Windows. Пока нормально не допилили wsl (Windows Subsystem for Linux) — долгое время я пользовался им. В сути, всё то же самое, что я выше описал для Linux, разве что это обычные exe-файлы, и работают под Windows: ssh, scp, ssh-keygen, ssh-copy-id. Работает всё, кроме удалённого монтирования папок, как я не пытался разрешить эту проблему и как не искал пакеты — так и не понял, как это можно сделать.

Как по мне, это самое простое и быстрое решение, потому что разворачивать wsl немного сложнее, чем просто скачать и запустить инсталлятор Cygwin.

▍ Путь настоящего джедая — Windows Subsystem for Linux

Если исключить установку linux на виртуальную машину, и шаринг папок по сети, то один из немногих известных мне (вменяемых) способов монтирования папок по ssh — использование подсистемы линукс для виндоус. Можно посмотреть следующий мануал и ужаснуться того, как же сложно это делается.

Но на самом деле, на Windows 11 wsl уже совсем хорошо и просто работает, без особых танцев с бубном и перенаправлением видео на программу X Server. На Windows 10 я ставил Ubuntu из магазина приложений, потом запускал какую-то команду в PowerShell, чтобы активировать wsl и получал готовый linux.

Это решение хорошо тем, что оно мгновенно запускается. Консоль linux запускается также быстро, как PowerShell или cmd. Также оно имеет доступ ко всем данным на жёстких дисках из коробки. Единственный нюанс — нельзя по сети монтировать папки в папки, принадлежащие ОС Windows.

Поэтому я монтирую папки в wsl, и там уже запускаю Visual Studio Code, скармливаю ей локальную папку и работаю в ней. Студия ругается на то, что я запускаю её под wsl. Для работы X11 в Windows 10 (в Windows 11 починили), точно также как для удалённого сервера надо устанавливать программу VcXsrv. Для того чтобы окна корректно открывались, нужно в машине wsl прописать адрес удалённого сервера X Windows (можно её сразу добавить в .bashrc):

export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0

Понимаю, что это может показаться очень сложным, но я так привык к удобству удалённых папок, что один раз в этом разобраться — точно стоит того. На данный момент при работе не возникает никаких проблем, когда понимаешь: что, почему и зачем нужно.

Вот, для примера точно так же монтирую удалённую папку home в wsl, и затем открываю её в Visual Studio Code:

Картинка с сайта: habr.com

Монтирование удалённой папки и перенаправление дисплея

После чего можно успешно всё открыть в VS Code.

Картинка с сайта: habr.com

Успешно открытая Visual Studio Code с удалённой папкой

Заключение

Ssh — это основной инструмент системного разработчика, администратора и даже продвинутого пользователя. Очень классный, простой, а главное — эффективный инструмент, который может решать массу задач.

Для меня самой большой болью было подружить Windows и ssh. Дружба эта — плохая, как воды и масла, но всё же, мне удаётся достаточно комфортно работать по ssh и под операционной системой Windows.

Ссылки

1. Прекрасная статья использования ssh в примерах. И её русский перевод на хабре. Единственное на что хочу обратить внимание, что там опущено то, как конфигурировать демона, и без корректной настройки на стороне сервера это работать не будет.
2. Пример создания обратного ssh-тунеля, в картинках, как почему, зачем.
3. Достаточно объёмный, и в той же мере бесполезный мануал по разворачиванию wsl. Но есть несколько полезных моментов, которые оттуда для себя почерпнул.

Картинка с сайта: habr.com

In this post I want to show how you can enable X11 forwarding by using PuTTY and the Xming X Server for Windows.

In order to use X11 forwarding, an X11 server needs to be installed on the client (in my case Windows here). Therefore you can use several X11 servers available for Windows, I will use here the Xming X Server which you download under https://sourceforge.net/projects/xming/.

X11 forwarding is supported by the SSH protocol that enables users to run graphical applications on a remote server and interact with them by using their local display and I/O devices.

Introduction

The X Window System (X11, or simply X) is a windowing system for bitmap displays, common on Unix-like operating systems.

X provides the basic framework for a GUI environment: drawing and moving windows on the display device and interacting with a mouse and keyboard. X does not mandate the user interface – this is handled by individual programs. As such, the visual styling of X-based environments varies greatly; different programs may present radically different interfaces.

X originated as part of Project Athena at Massachusetts Institute of Technology (MIT) in 1984. The X protocol has been at version 11 (hence “X11”) since September 1987. The X.Org Foundation leads the X project, with the current reference implementation, X.Org Server, available as free and open-source software under the MIT License and similar permissive licenses.

Source: https://en.wikipedia.org/wiki/X_Window_System

SSH Server Configuration

X11 Forwarding is by default enabled on most SSH servers. Below for example is the default configuration on Linux Enterprise Server 15 under /etc/ssh/sshd_config.

X11Forwarding yes
Specifies whether X11 forwarding is permitted. The default is yes. Note that disabling X11 forwarding does not improve security in any way, as users can always install their own forwarders.

X11UseLocalhost yes
Specifies whether sshd should bind the X11 forwarding server to the loopback address or to the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. However, some older X11 clients might not function with this configuration. X11UseLocalhost can be set to no to specify that the forwarding server should be bound to the wildcard address. The argument must be yes or no. The default is yes.

The X server is listening on the loopback address for incoming request from X clients (GUI applications running on the server).

Prerequisites

When you will try to use X11 forwarding before you have configured X11 forwarding in PuTTY and running a X11 server on Windows, you will run into the following error.

Gtk-Warning: cannot open display:

Enable X11 forwarding in PuTTY by checking the Enable X11 forwarding and for the authentication protocol leave the MIT-MAGIC-COOKIE-1 protocol as already selected by default under the sessions SSH -> Auth -> X11 forwarding settings as shown below.

The X display location below is by default localhost:0 which you normally don’t have to enter here, just in case you have some issues, you can set it explicitly here.

The MIT-MAGIC-COOKIE-1 authorization protocol was developed by the Massachusetts Institute of Technology (MIT). A magic cookie is a long, randomly generated binary password. At server startup, the magic cookie is created for the server and the user who started the system. On every connection attempt, the user’s client sends the magic cookie to the server as part of the connection packet. This magic cookie is compared with the server’s magic cookie. The connection is allowed if the magic cookies match, or denied if they do not match.

Source: https://docs.oracle.com/cd/E19620-01/805-3921/security-4/index.html

When now trying again after enabled X11 forwarding in PuTTY but without a local running X11 server on your client computer, you will encounter the following additional error message.

PuTTY X11 proxy: unable to connect to forward X server: Network error: Connection refused

So we first need to install a X server on Windows as shown below.

Install Xming Server on Windows

Xming is the leading X Window System Server for Microsoft Windows. It is fully featured, small and fast, simple to install and because it is standalone native Microsoft Windows, easily made portable (not needing a machine-specific installation).

Source: https://sourceforge.net/projects/xming/

You can download the Xming server under the link above.

By default Normal PuTTY Link SSH client is checked which will also install the PuTTY client. Because I had already PuTTY installed I will not install the SSH client here.

Display settings

After the installation you can adjust some settings by using the XLaunch tool as shown below.

Click through the wizard with Next.

Testing X11 Forwarding by using the GParted tool

Now it works and the applications GUI will be forwarded (proxied) to my local running Xming X server on Windows which will finally display the GUI application on my Windows computer.

Understanding the X11 DISPLAY environment variable and how X11 Forwarding works?

An X Display is generally made up of at least one screen, keyboard, and pointer device. In this context, a screen is not a physical monitor, rather a virtual canvas which can read raw graphical data. In practice a single screen can be made up of multiple monitors and other virtual displays.

The X Display is managed by the X server.

X Client Programs use the $DISPLAY environment variable, which looks like hostname:display_number.screen_number, to determine which X Display to connect to. An X Program can derive a tcp or unix socket from this value to form a connection to the display through the X Server. Once the connection is accepted, the X Server forwards the connection to the requested screen.

Source: https://goteleport.com/blog/x11-forwarding/

Below the content of the DISPLAY environment variable when a user logs in by using SSH from remote with PuTTY.

Xorg listens on port 6000+n, where n is the display number. This connection type can be disabled with the -nolisten option (see the Xserver(1) man page for details).

Source: https://www.x.org/archive/X11R6.8.0/doc/Xorg.1.html

Below the content of the DISPLAY environment variable when a user logs in locally directly to the console of the server.

On most platforms, the Local connection type is a UNIX-domain socket (also used below). On some System V platforms, the local connection types also include STREAMS pipes, named pipes, and some other mechanisms.

Source: https://www.x.org/archive/X11R6.8.0/doc/Xorg.1.html

To demonstrate the use of the TCP/IP sockets and UNIX-domain sockets by the X server, I will use below the ss (socket statistics) tool.

First I will list the DISPLAY environment variable and TCP/IP sockets for the remote SSH connection (X11 forwarding) initiated by PuTTY :

echo $DISPLAY
ss -a -n -t

In the output you can see that the X server is listening here for this remote session on TCP/IP IPv4 and IPv6 on port 6010. The display number for this remote session is 10 as seen in the output of the DISPLAY environment variable.

Note!
Xorg listens on port 6000+n, where n is the display number.

Source: https://www.x.org/archive/X11R6.8.0/doc/Xorg.1.html

Then I will list the UNIX domain sockets (IPC) for the local console connection directly on the server itself by using:

ss -x -a | grep X11


Display All TCP Sockets
# ss -t -a

Display All UDP Sockets
# ss -u -a

Display All RAW Sockets
# ss -w -a

Display All UNIX Sockets
# ss -x -a

Processes on the same host can communicate via UNIX domain sockets (IPC).

How does X11 Forwarding work in detail?

X11 Forwarding follows the same model as X11, but the X Client to X Server connection gets tunneled through an SSH Channel. In order to achieve this flow, the SSH Server proxies the remote X Client connection to the SSH Client, and the SSH Client proxies it to the user’s X Server.

The article below will dig deep and explains great about how X11 Forwarding works in detail.

Source: https://goteleport.com/blog/x11-forwarding/

X.Org Server

X.Org Server is the free and open-source implementation of the X Window System (X11) display server stewarded by the X.Org Foundation.

The X.Org Server runs on many free-software Unix-like operating systems, including being adopted for use by most Linux distributions and BSD variants. It is also the X server for the Solaris operating system. X.Org is also available in the repositories of Minix 3.

Source: https://en.wikipedia.org/wiki/X.Org_Server

Links

PuTTY
https://www.putty.org/

Xming X Server for Windows
https://sourceforge.net/projects/xming/

X Window System Protocol
https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html

X.Org project
https://www.x.org/wiki/

X.Org Server
https://en.wikipedia.org/wiki/X.Org_Server

X.Org Foundation
https://en.wikipedia.org/wiki/X.Org_Foundation

How does X11 Forwarding work?
https://goteleport.com/blog/x11-forwarding/