Ubuntu 18.04 LTS x11vnc больше не работает

3

Недавно я изменил с Ubuntu 16.04 LTS на 18.04 LTS, так как мне нужна была новая версия kvm / qemu.

С 16.04 я смог легко запустить службу x11vnc (daemon), выполнив инструкции из «Community Help Wiki»: Ссылка

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

Изначально я ничего не делал с моей чистой установкой 18.04, кроме добавления скрипта systemctl точно в соответствии с инструкциями «Справка сообщества»: «Имейте x11vnc запускать автоматически через systemd в любой среде (Vivid +)».

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

  1. Диспетчер отображения отключен «Wayland», отредактировав /etc/gdm3/custom.conf и установив WaylandEnable=false в этом скрипте:

    [daemon]
    # Uncoment the line below to force the login screen to use Xorg
    #WaylandEnable=false
    WaylandEnable=false  <--- HERE
    
  2. Изменена команда /lib/systemd/system/x11vnc.service ExecStart , чтобы использовать другую директиву xauth , так как в 18.04, как представляется, автоматически не создается файл $HOME/.Xauthority , который можно найти с помощью директивы -xauth guest :

    From:

    ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /home/USERNAME/.vnc/passwd -rfbport 5900 -shared
    

    To:

     ExecStart=/usr/bin/x11vnc -auth /run/user/120/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/USERNAME/.vnc/passwd -rfbport 5920 -shared
    

Я сделал это, основываясь на некоторых чтениях и тестировании на Xauthority, которые указали, что местоположение токена .Xauthority теперь предоставляется через переменную среды $XAUTHORITY .

Чтобы найти значение этого, я запускаю следующую команду « find », чтобы определить, какие процессы имеют переменную среды XAUTHORITY .

ПРИМЕЧАНИЕ: для поиска переменных среды процесса используется файловая структура linux /proc/<procid>/environ ,

cd /proc
sudo find . -maxdepth 1 -type d -exec sh -c "(test -f '{}'/environ && cat '{}'/environ | tr '
sudo find . -maxdepth 1 -type d -exec sh -c "(test -f '{}'/environ && grep -aH XAUTHORITY= '{}'/environ )" \;
' '\n' | grep XAUTHORITY= )" \;

Это привело к двум различным результатам:

  • XAUTHORITY=/run/user/120/gdm/Xauthority
  • XAUTHORITY=/run/user/1000/gdm/Xauthority

Затем я использовал следующее, чтобы найти соответствующие идентификаторы процессов:

240 tty1     Sl+    0:00 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
14923 tty2     Sl+    0:00 /usr/lib/gnome-session/gnome-session-binary --session=ubuntu

Соответствующие процессы для них:

13/05/2018 16:19:14 *** XOpenDisplay failed.

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

Дальнейшая проверка переменных окружения показывает, что у кого USER=gdm , а у другого есть USER=<ME>

Проблема заключается в том, что если я использую «greeter» auth location, тогда мне будет предложено указать пароль, за которым следует черный / пустой экран. Если я использую пользовательское местоположение auth, то я вообще не получаю никакого клиентского соединения, так как статус возвращает ошибку, что он не может открыть Дисплей:

%pr_e%

Итак, кажется, что вы попадаете в изменение механизма xauth.

Может кто-нибудь, пожалуйста, дайте некоторые рекомендации по этому поводу?

    
задан zebity 13.05.2018 в 06:38
источник

3 ответа

2

У меня была такая же проблема, и после некоторого разговора с x11vnc и gdm я решил просто переключиться обратно на lightdm:

apt install lightdm

Это должно привести к конфигурации диспетчера дисплеев. Если не запустить:

dpkg-reconfigure lightdm

Теперь я запускаю свой сервер x11vnc через супервизор со следующей конфигурацией:

$ cat /etc/supervisor/conf.d/x11vnc.conf
[program:x11vnc]
command=/usr/bin/x11vnc -xkb -safer -nopw -once -geometry 1024x768 -auth /var/run/lightdm/root/\:0 -display :0
user=root
autorestart=true

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

$ cat /etc/supervisor/conf.d/novnc.conf
[program:noVNC]
command=/opt/noVNC/utils/launch.sh --vnc localhost:5900
user=root

$ cat /etc/nginx/sites-enabled/novnc
upstream vnc_proxy {
    server 127.0.0.1:6080;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    include snippets/snakeoil.conf;

    root /var/www/html;

    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
            auth_pam               "Secure Zone";
            auth_pam_service_name  "nginx";
            proxy_pass http://vnc_proxy/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            keepalive_requests 10000;

            proxy_read_timeout 61s;

            proxy_buffering off;
    }
}

Возможно, вы захотите обернуть вокруг него дополнительную защиту.

    
ответ дан Uli 15.05.2018 в 12:38
источник
1

Пользователи Ubuntu 18.04 x11vnc.

Вот «хакерский ответ», который позволяет вам получить доступ к VNC без входа в систему.

Я говорю «взломать», поскольку он включает в себя 2 службы x11vnc.

Во-первых, разрешить вход через DISPLAY=:0 , а второй - использовать VNC для доступа к рабочему столу через DISPLAY=:1

Для этого я использовал следующие 2 сценария демона:

Первое: x11vnc-login.service только для приветствия входа

[Unit]
Description=Start x11vnc-login at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth /run/user/120/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/<ID>/.vnc/password -rfbport 5922 -shared -display :0
[Install]
WantedBy=multi-user.target

Второй: x11vnc.service for desktop :

[Unit]
Description=Start x11vnc at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth /run/user/1000/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/<ID>/.vnc/password -rfbport 5920 -shared -display :0
[Install]
WantedBy=multi-user.target

Установка и включение скриптов выполняется по документации на сайте сообщества .

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

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

Очевидно, что необходимо иметь некоторый скрипт, который выполняет предварительный поиск запущенных процессов, чтобы узнать, зарегистрирован ли пользователь, и если да, тогда просто используйте информацию XAUTHORITY / DISPLAY из существующего раздела пользователя (как извлечено из / proc / PROCID / environ, в противном случае подключите сокет до экрана приветствия с помощью приветствия XAUTHORITY / DISPLAY, а затем каким-то образом переместите соединение сокета на другой сеанс x11vnc, используя пользовательские значения XAUTHOURITY / DISPLAY.

Я подозреваю, что существует сложное программирование для файлового дескриптора fork / socket / file.

Другая возможность - выяснить, есть ли способ заставить диспетчер отображения 18.04 вести себя согласно предыдущему 16.04.

    
ответ дан zebity 15.05.2018 в 12:15
источник
0

Самый простой способ получить эту работу снова - переключение с GDM3 на LightDM.

Что, кстати, абсолютно не отменяет / отступает в любом случае.

ubuntu 18.04 подключиться к экрану входа в систему через VNC

    
ответ дан Seb 17.06.2018 в 13:06
источник

Ознакомьтесь с другими вопросами по меткам