Запуск VNC

попробуй такое с рутовыми привилегиями:

x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbport 5900 -localhost -shared

То есть автоматом запустить возможно только x11vnc, остальные сервера только ручками? А в какой скрипт эту строку добавлять, чтобы запускался автоматом до логина пользователя.
Вопрос серьёзный, вот в соседней теме юзер, только что слезший с винды спрашивает, что использовать вместо TeamViewer. Ему отвечают - VNC используй. А как использовать, если ни один vnc-сервер из коробки не работает?

То есть автоматом запустить возможно только x11vnc, остальные сервера только ручками?

запустить то можно, только не факт, что TigerVNC умеет логин скрин отображать. На убунте у меня была проблема с vnc4server - x0vnc4server должен шарить физические иксы, но если юзер не залогинен то не работало, поэтому остановился на x11vnc, а TigerVNC в репах убунты не было, так что не проверял

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

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

А как использовать, если ни один vnc-сервер из коробки не работает?

Просто под словом «работает» клепальщики дистров понимают нечто своё, недоступное пониманию бывших пользователей TeamViewer

Просто под словом «работает» клепальщики дистров понимают нечто своё, недоступное пониманию бывших пользователей TeamViewer

Я больше скажу, создатели VNC-серверов, и возможно, протокола VNC, под словом «работает» понимают нечто, совершенно отличное от того, что под этим словом понимают производители других remote desktop. Достаточно вспомнить извечные проблемы с вводом с клавиатуры на разных языках. Да и с совместимостью различных способов авторизации на разных комбинациях клиент/сервер там просто песня...

Просто под словом «работает» клепальщики дистров понимают нечто своё, недоступное пониманию бывших пользователей TeamViewer

«Если такой умный, взял бы да и сделал» (c)

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

Это можно обойти только если на данной машине есть только один пользователь кроме root, которому позволяется работать в x-ах, для этого в скрипте, который запускает session manager можно будет принудительно устаналивать разрешения на /tmp/*.Xauthority* и копирования его в ~$USER/.Xauthority

взял бы да и сделал

Ну так я и сделал

Ну так я и сделал

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

А потом удивляются, почему так в дистрибутивах не делают...

Ась? Оно позволяет получить логин скрин свежеребутнутого компа и залогиниться там в гуй под любой нужной учеткой

И что произойдёт, когда vnc соединение прервётся? Любой пользователь сможет подключиться к залогиненому другому пользователю?

Общий display :0 это не баг, а фича в данном случае. Использую чтоб на личный домашний комп иногда заходить, ни каких других юзеров там нет. Посмотрел что нужно - залочил скрин. Не RDP конечно, но что уж тут. А твой способ позволяет зайти VNC на ребутнутый комп?

А твой способ позволяет зайти VNC на ребутнутый комп?

Конечно, это ровно тоже самое, только доступ к auth имеет выбранный пользователь, потому секурность страдает не сильно, ибо xvnc можно вообще запускать самим пользователем после входа по ssh.

тогда подробнее про копирование и разрешения

При запуске X-ов создаётся (обычно в /tmp) xauth файл, его имя можно увидеть в 14-й колонке ps -ax. Копируем его в домашний каталог выбранного пользователя и устанавливаем chown на этого пользователя. А xvnc запускаем от пользователя, или через sudo -u user или вообще сам пользователь зайдя по ssh с тунелем для 5500 порта с хорошей шифрацией самим ssh сам и запустит xvnc.

У меня этот греп показывает такое:

ps -ax | grep X
 6734 pts/11   S+     0:00 grep --color=auto X
 9676 tty7     Ssl+  55:31 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

я так понял?

Да, надо было написать «где-то 14-е поле» :)

тогда для убунты получается примерно так:

ps -ax | grep X | awk '{print $11}' |grep -v ^$

еще один. зачем вам, болезненным, в линупсе vnc?? цеж костыль! чем x2go не уgoдил?

щас попробую где-нибудь проверить

щас попробую где-нибудь проверить

Вы сомневаетесь в рабочем решении? И что всем делать, если у вас не получится? ;)

Проверю, что всё правильно понял, нет - дальше будем разбираться =)

Ну, например, иногда надо подключаться к сессии запущенной на уже существующем инстансе X-сервера, а не запускать еще одну отдельную.

Можно использовать xorg-модуль TigerVNС.

Создайте файл /etc/X11/xorg.conf.d/10-libvnc.conf содержащий текст

Section "Module"
        Load "vnc"
EndSection

Section "Screen"
        Identifier "Default Screen"
        Option "CompareFB" "0"
        Option "SecurityTypes"  "VncAuth"
        Option "UserPasswdVerifier" "VncAuth"
        Option "PasswordFile" "/root/sec/xvnc-passwd"
        Option "localhost" "1"
EndSection

перезапустите X-ы.

Засада, в хомяке уже есть .Xauthority и копирование /var/run/lightdm/root/:0 ни чего не меняет (x0vnc4server работает из-под обычного юзера, x11vnc работает из-под обычного юзера). Попозже ребутну посмотрю после ребута как будет, может сломается x0vnc4server. И это, что-то я не понял, сам vnc сервер с какими опциями запускаешь? С авторизацией что ли?

Вы думаете, что ваши путанные мысли кого-то волнуют? ;)

сам vnc сервер с какими опциями запускаешь?

Я запускаю через ssh -C -L 5900:localhost:5900 $REMOTE x11vnc -localhost -auth /home/vodz/.Xauthority -passwd XXXX

и ЧО. x2go отлично подключается к уже запущенной сессии.

x0vnc4server vs x11vnc (комментарий)

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

Вот так вот, линуксойды любят говорить «хренли», «ненужно», а потом удивляются почему другие по прежнему выбирают оффтопик.
Без автозапуска я пользовался таким способом:
1. Запускаешь ssh-клиент с параметром -L 5900:127.0.0.1:5900
2. В ssh клиенте запускаешь X-сессию «xinit /usr/bin/startxfce4 :0 — /usr/bin/Xvnc :0 -geometry 800x600 -localhost -rfbport 5900 -SecurityTypes None»
3. Затем VNC-клиентом коннектишься к 127.0.0.1:5900
Всё бы хорошо, но:
1. Меня напрягает то, что нельзя подключаться как винде через RDP, AMYadmin и TeamViewer по принципу «взял и подключился», а нужно выполнять эти пункты.
2. Сессия иногда рвётся и вместе с ней в тартарары летит VNC-сервер вместе с рабочим столом, всеми запущенными на нём программами и несохранёнными данными.
3. Этот способ возможен только если перед этим на удалённом компьютере ни один сервер не был запущен.

Честно говоря я ещё не успел сходить по всем ссылкам, которые даны в теме. Я выше описал как я изредка использую TigerVNC и как коряв этот способ.
Правильно ли я понимаю, что отличие принципа работы TigerVNC от x11vnc и vnc4server в том, что первый запускает свой собственный Сервер, а два других подключаются к уже запущенному Xorg? При этом, если на компьютере используется логин через менеджер дисплеев, использовать x11vnc и vnc4server для логина в нём по VNC не получится? То есть универсальной программы, которая позволяла бы удалённому пользователю как подключаться к запущенной X-сессии, так и создавать новую в линуксе не существует.

еще один. зачем вам, болезненным, в линупсе vnc?? цеж костыль! чем x2go не уgoдил?

А оно умеет удалённо логиниться в менеджере дисплеев?

И что произойдёт, когда vnc соединение прервётся? Любой пользователь сможет подключиться к залогиненому другому пользователю?

Что-то я не вижу проблемы. Можно легко закрыть 5900 порт через iptables, тогда подключение будет возможно только через ssh-тоннель.

Что-то я не вижу проблемы. Можно легко закрыть 5900 порт через iptables, тогда подключение будет возможно только через ssh-тоннель

Типичный LOR, прочитать вдумчиво тред не могут, не видят, зато обхамить всех подряд — это запросто. Причём тут iptables, когда вышепреведенный тред вообще был о localhost:5900 и подключение через прокидывание поверх ssh?!

Ну я подумал, что вы про подключение поверх ssh не разглядели, потому что при таких раскладах ситуация «любой пользователь сможет подключиться к залогиненому другому пользователю» невозможна в принципе, если конечно пользователь не будет свой пароль или закрытый ключ для ssh давать всем подряд.

Речь не о подключении к хосту. Речь о подключении к дисплею vnc. Автор предлагал поднимать подключение в стартовом скрипте с подключением непосредственно к session manager с root-правами аутентификации сессии. Пока пользователь не залогинился, всё вроде бы нормально. Но, если связь по vnc оборвалась, то любой пользователь, как-либо оказавшийся на хосте мог бы подключиться к дисплею залогиненого и незаблокированного пользователя.

Мне тут недавно пришлось костылять юнит для x11vnc, чтобы обойти известную проблему с light-locker'ом, кучу дисплеев иксовых поднимающим на разных tty. Благо, старый добрый x11vnc умеет ждать появления дисплея, если его еще нет.

/etc/systemd/system/x11vnc@.service

[Unit]
Description=VNC Server for X11
Requires=graphical.target
After=graphical.target

[Service]
Type=forking
ExecStart=/usr/bin/x11vnc -display WAIT:%i -auth /var/run/lightdm/root/:%i -norc -forever -shared -bg -rfbauth /etc/x11vnc.pass -autoport 590%i -o /var/log/x11vnc-display-%i.log
Restart=always

[Install]
WantedBy=graphical.target

systemctl start x11vnc@0

Грязный костыль

Действительно. Ведь можно же поставить в зависимость от старта X-ов. Ну и сразу же хочется услышать как оно насчёт мысли указанной в предыдущем к вашему комментарии?

light-locker дисплеи поднимает и выключает в ходе своей работы, если ставить в зависимость от старта иксов, надо каким-то образом передавать номер дисплея в x11vnc, а эта шняга (я про light-locker) не умеет в скрипты. А насчет того коммента не очень понял. У меня, как и у тс, цель в удаленном доступе к текущей сессии, а не в терминальном. Для терминала нужно поднимать xrdp или x2go.

А насчет того коммента не очень понял.

У вас же нет даже -passwd опции, потому любой пользователь подключится к текущей сессии любого пользователя?

Как это нет? А вот это что?

-rfbauth /etc/x11vnc.pass

Я вот еще подумал, может что-то можно на inotify накостылять на баше, чтобы мониторилось появление новых файлов в /var/run/lightdm/root/, и в зависимости от этого поднимались/прибивались новые x11vnc...

А оно умеет удалённо логиниться в менеджере дисплеев?

ты про gdm/lightdm? нет. он сам является аналогом gdm. из гуя можно поднять новую сессию, либо приаттачиться к существующей. да и к тому же использует нативный X11Forwarding. зачем тащить всякие vnc поделки?

Как это нет? А вот это что?

А блин, понаделали опций, думал на нее, но поленился проверить :)

Но с другой стороны, если vnc-сессий у вас много, а файл с паролями один, то получается всё тоже самое, о чём был вопрос - как разрулить защиту пользователей друг от друга.

защиту пользователей друг от друга

Как уже выше писал, такая задача не стоит в принципе. т.к. это не терминальный доступ, а доступ к своей машине (в случае ТС) и саппорт (в моем случае). Для терминального доступа другие инструменты.

Тогда не понятно, откуда у вас там много дисплеев.

Это фишка light-locker. При блокировке экрана и/или смене пользователя он переползает на другой vt.

Все же накостылял, может пригодится кому.


/etc/systemd/system/x11vnc@.service

[Unit]
Description=VNC Server for X11
Requires=graphical.target
After=graphical.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -display WAIT:%i -auth /var/run/lightdm/root/:%i -norc -forever -shared -rfbauth /etc/x11vnc.pass -autoport 5900 -o /var/log/x11vnc-display-%i.log
SuccessExitStatus=2
RestartPreventExitStatus=2
Restart=always

[Unit]
Description=X11VNC displays autodetect for light-locker
Requires=graphical.target
After=graphical.target

[Service]
Type=simple
ExecStart=/usr/local/bin/x11vnc-light-locker
Restart=always

[Install]
WantedBy=graphical.target

#!/bin/bash

while inotifywait -qq -e modify /sys/class/tty/tty0/active; do
	CURRDSP=$(ps x | grep vt$(cat /sys/class/tty/tty0/active | sed 's/tty//g') | grep Xorg | awk '{print $11}' | awk -F: '{print $2}')
	/bin/systemctl stop x11vnc@*
	if [[ $CURRDSP ]]; then
		/bin/systemctl start x11vnc@$CURRDSP
	fi
done

systemctl enable x11vnc@0 --now

systemctl enable x11vnc-light-locker --now

Еще мне не нравится потенциальная неспособность этих костылей переварить номера дисплеев, отличные от простых цифр без точек и прочего

Может потому, что вы не знаете sed и awk ? ;) Зачем cat file | sed, если sed file делает ровно то, что вы хотите? Да и вообще, вся эта конструкция из «grep | grep | awk | awk» может быть заменена на один несложный скрипт для awk.

Да проблема не в костыльной конструкции из пайпов, слепленной на скорую руку (цели «сделать красиво» и не было, ибо все равно нужно менять всю строку по-хорошему), а в источнике, который парсится.

И да, вся эта конструкция по-нормальному выглядит примерно так

ps -fC Xorg | grep vt$(sed 's/tty//g' /sys/class/tty/tty0/active) | sed -e 's/\(^\)\(.*\)\/var\/run\/lightdm\/root\/\:\s*\(.*\)/\1\3/; s/ .*//'

Наверное.

А в чём удобность запускать X-ы на новом дисплее при смене tty?

Это надо у разработчиков lightdm/light-locker спрашивать, возможно, так более надежно лочится сессия?

А если нужно вместо -rfbauth через -accept xmessage подключение?

Не работает В логах ругается на Error: Can't open display: rawfb

05/03/2019 15:34:05 running command:

xmessage -buttons yes:0,no:2,view-only:3 -center 'x11vnc: accept connection from 192.168.1.10?'

Error: Can't open display: rawfb 05/03/2019 15:34:05 command returned: 1 05/03/2019 15:34:05 accept_client: process action line: yes:0,no:*,view:3 05/03/2019 15:34:05 accept_client: default action is case=2 no