Удаленный доступ через линукс

Установка и настройка xrdp для использования удаленного рабочего стола в Ubuntu

Если вы не знакомы с Linux или для быстрого устранения неполадок, использование удаленного рабочего стола может быть проще, чем доступ к Secure Shell (SSH). В этой статье описывается установка и настройка среды рабочего стола (xfce) и удаленного рабочего стола (xrdp) для виртуальной машины Linux под управлением Ubintu.

Эта статья была написана и протестирована для виртуальной машины с Ubuntu 18.04.

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

Предварительные требования

Для работы с этой статьей требуется существующая виртуальная машина Ubuntu 18.04 LTS или Ubuntu 20.04 LTS в Azure. Если требуется создать виртуальную машину, используйте один из следующих методов:

Установка среды рабочего стола на виртуальной машине Linux

На большинстве виртуальных машин Linux в Azure по умолчанию не установлена среда рабочего стола. Виртуальные машины Linux обычно управляются с помощью SSH-подключений, а не среды рабочего стола, однако существует несколько сред рабочего стола, которые можно установить. В зависимости от выбранной среды рабочего стола она занимает до 2 ГБ дискового пространства и занимает до десяти минут, чтобы установить и настроить все необходимые пакеты.

С помощью приведенного ниже примера кода можно установить упрощенную среду рабочего стола xfce4 на виртуальной машине Ubuntu. Команды для других дистрибутивов незначительно отличаются. Например, для установки на виртуальной машине Red Hat Enterprise Linux используйте yum и настройте соответствующие правила selinux , а для установки на виртуальной машине SUSE используйте zypper .

Сначала установите SSH-подключение к виртуальной машине. Следующий пример подключается к виртуальной машине myvm.westus.cloudapp.azure.com с использованием имени пользователя azureuser. Используйте собственные значения:

ssh azureuser@myvm.westus.cloudapp.azure.com 

Если вы используете Windows и вам нужны дополнительные сведения об использовании SSH, см. статью Использование ключей SSH в Windows.

Затем установите xfce с помощью apt :

sudo apt-get update sudo DEBIAN_FRONTEND=noninteractive apt-get -y install xfce4 sudo apt install xfce4-session 

Установка и настройка сервера удаленных рабочих столов

Теперь, когда у вас установлена среда рабочего стола, настройте службу удаленных рабочих столов для прослушивания входящих подключений удаленного доступа. xrdp — это сервер открытый код протокола удаленного рабочего стола (RDP), который доступен в большинстве дистрибутивов Linux и хорошо работает с xfce. Установите xrdp на виртуальной машине Ubuntu следующим образом:

sudo apt-get -y install xrdp sudo systemctl enable xrdp 

В Ubuntu 20 необходимо предоставить доступ к сертификату пользователю xrdp:

sudo adduser xrdp ssl-cert 

Укажите, какую среду рабочего стола должен использовать сервер xrdp при запуске сеанса. Настройте xrdp для использования xfce в качестве среды рабочего стола с помощью следующего кода:

echo xfce4-session >~/.xsession 

Перезапустите службу xrdp, чтобы изменения вступили в силу:

sudo service xrdp restart 

Настройка пароля локальной учетной записи пользователя

Если вы создали пароль для учетной записи пользователя при создании виртуальной машины, пропустите этот шаг. Если вы используете только проверку подлинности по ключу SSH и не используете пароль локальной учетной записи, укажите пароль перед использованием xrdp для входа в виртуальную машину. Xrdp не может принимать ключи SSH для проверки подлинности. В следующем примере задается пароль для учетной записи пользователя azureuser.

После указания пароля конфигурация SSHD не обновится таким образом, чтобы разрешить вход с помощью пароля, если такая возможность в настоящее время не настроена. С точки зрения безопасности лучше подключиться к виртуальной машине через туннель SSH с помощью проверки подлинности на основе ключа, а затем подключиться к xrdp. В таком случае можно пропустить следующий шаг по созданию правила группы безопасности сети, разрешающего трафик с удаленного рабочего стола.

Создание правила группы безопасности сети, разрешающего трафик с удаленного рабочего стола

Чтобы трафик с удаленного рабочего стола мог поступать на виртуальную машину Linux, необходимо создать правило группы безопасности сети, разрешающее использовать протокол TCP на порту 3389 для доступа к виртуальной машине. Дополнительные сведения о правилах группы безопасности сети см в разделе Что такое группа безопасности сети? Для создания правила группы безопасности сети можно также использовать портал Azure.

В следующем примере создается правило группы безопасности сети с именем az vm open-port на порту 3389. Из Azure CLI, а не сеанса SSH с виртуальной машиной, откройте следующее правило группы безопасности сети:

az vm open-port --resource-group myResourceGroup --name myVM --port 3389 

В следующем примере в существующую группу безопасности сети добавляется правило группы безопасности сети с add-AzNetworkSecurityRuleConfig через порт 3389. Получите существующую группу безопасности сети, именуемую myVMnsg, из Azure PowerShell, не из сеанса SSH для вашей виртуальной машины:

$nsg = Get-AzNetworkSecurityGroup -ResourceGroupName myResourceGroup -Name myVMnsg 

Добавьте правило безопасности сети RDP с именем open-port-3389 в $nsg группу безопасности сети и обновите группу безопасности сети с помощью Set-AzNetworkSecurityGroup, чтобы изменения вступили в силу:

$params = @ < Name = 'open-port-3389' Description = 'Allow RDP' NetworkSecurityGroup = $nsg Access = 'Allow' Protocol = 'TCP' Direction = 'Inbound' Priority = 100 SourceAddressPrefix = 'Internet' SourcePortRange = '*' DestinationAddressPrefix = '*' DestinationPortRange = '3389' >Add-AzNetworkSecurityRuleConfig @params | Set-AzNetworkSecurityGroup 

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

Откройте локальный клиент удаленного рабочего стола и подключитесь с помощью IP-адреса или DNS-имени виртуальной машины Linux.

Введите имя пользователя и пароль для учетной записи пользователя на виртуальной машине:

После проверки подлинности загрузится среда рабочего стола xfce. Она будет выглядеть примерно так:

Если локальный RDP-клиент использует проверку подлинности на уровне сети (NLA), то может потребоваться отключить эту настройку подключения. В настоящее время XRDP не поддерживает NLA. Вы можете также воспользоваться альтернативными решениями для RDP, которые поддерживают NLA, такими как FreeRDP.

Диагностика

Если вы не можете подключиться к виртуальной машине Linux с помощью клиента удаленного рабочего стола, используйте netstat на виртуальной машине Linux, чтобы убедиться, что виртуальная машина прослушивает RDP-подключения, как показано ниже.

sudo netstat -plnt | grep rdp 

В следующем примере показана виртуальная машина, прослушивающая TCP-порт 3389, как и ожидалось:

tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 53192/xrdp-sesman tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 53188/xrdp 

Если служба xrdp-sesman не прослушивает, на виртуальной машине Ubuntu перезапустите службу следующим образом:

sudo service xrdp restart 

Просмотрите журналы в папке /var/log на виртуальной машине Ubuntu, чтобы узнать, почему служба не отвечает. Вы также можете проверять системный журнал на предмет ошибок во время попыток подключения к удаленному рабочему столу:

В других дистрибутивах Linux, например Red Hat Enterprise Linux и SUSE, способы перезапуска служб и расположение файла журнала могут отличаться.

Если вы не получили никакого ответа в клиенте удаленного рабочего стола и не видите никаких событий в системном журнале, это означает, что трафик удаленного рабочего стола не может достичь виртуальной машины. Проверьте правила групп безопасности сети и убедитесь, что в их числе есть правило, разрешающее трафик по протоколу TCP через порт 3389. Дополнительные сведения см. в статье Устранение проблем с подключением к приложениям на виртуальных машинах Linux в Azure.

Дальнейшие действия

Дополнительные сведения о создании и использовании ключей SSH на виртуальных машинах Linux см. в статье Создание пары из открытого и закрытого ключей SSH для виртуальных машин Linux.

Сведения об использовании SSH в Windows см. в статье Использование SSH с Windows в Azure.

Источник

Не только VNC и RDP. Удаленный рабочий стол Linux с X2Go

Однажды мне потребовалось организовать удаленный доступ к графическому интерфейсу Ubuntu. При этом необходимо было найти решение on-premise, поскольку использовать его предполагалось в корпоративной сети, где доступ к чувствительной информации исключал облачные решения вроде TeamViewer. Кроме того, канал связи с удаленной машиной обладал низкой пропускной способностью.

Сначала я перебрал несколько вариантов знакомых мне решений:

• VNC (Virtual Network Computing) — старый протокол, который основан на передаче массивов пикселей по протоколу RFB (Remote Framebuffer) для организации удаленного соединения. Он оказался слишком медленным и требовательным к пропускной способности каналов передачи данных. Особенно это критично для корпоративных сетей, подключенных через VPN, которые хостятся в другой части света;
• RDP (Remote Desktop Protocol) — протокол, который позволяет отправлять более сложные графические примитивы и высокоуровневые команды. Обычно используется для организации служб удаленных рабочих столов в Windows, но серверы для Linux также доступны, например xRDP. К минусам можно отнести сложность настройки/конфигурации на стороне хоста.

Я продолжил поиски и открыл для себя еще один способ организации удаленного рабочего стола — протокол NX.

Что такое NX?

В Linux для работы с графическими интерфейсами (GUI) используется X-сервер. Обычно окружения рабочего стола вроде GNOME, KDE или LXDE запускаются поверх Х-сервера, что позволяет запускать другие программы.

Компания NoMachine решила оптимизировать подключение к X-серверу по сети. Так появился протокол NX, который значительно снизил нагрузку на сеть.

NX — это не просто протокол доставки картинки, а, по сути, терминальный сервер для Linux. Он позволяет в удаленной операционной системе авторизовать пользователя, организовать для него полноценный сеанс и запустить в нем графическое окружение. Тот же VNC так не умеет.

На протяжении нескольких лет NoMachine развивала протокол как одноименный коммерческий продукт — NoMachine — и как community-проект FreeNX. Выпуская четвертую версию продукта, NoMachine решила больше не развивать FreeNX. Но сообщество осталось, и от основного репозитория отделилось много форков. Многие были уверены, что лучше знают, как надо. И некоторые из них оказались правы. Так, кроме FreeNX появились X2Go, QVD, RX, Neatx (от Google). Все эти протоколы друг с другом несовместимы, а некоторые уже “умерли”. Я выбрал X2Go.

Преимущества X2Go

Главные преимущества open-source реализации протокола NX X2Go перед аналогами — это:

• Высокая скорость в условиях низкой пропускной способности канала передачи данных;
• Простота настройки на стороне хоста. Т.к. X2Go работает через SSH, то все, что нужно сделать, — это убедиться, что SSH работает и порт 22 открыт в настройках файервола;
• Безопасность — протокол работает поверх SSH (пользователю доступны безопасные механизмы аутентификации, в том числе с ключами). Нет необходимости открывать дополнительный порт в настройках файервола.

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

Также доступны трансляция клиенту звука и видео с сервера, печать на локальном принтере и общие каталоги.

Как установить X2Go

Установка сервера на примере Ubuntu

Стабильные версии сервера и клиента X2Go можно установить из штатных репозиториев актуальных релизов Ubuntu. Необходимо инсталлировать два пакета:

sudo apt-get install x2goserver x2goserver-xsession

Проверяем, что сервер запущен:

sudo systemctl status x2goserver

Если вы используете не Xfce, возможно, потребуется установить дополнительные пакеты для графических оболочек. Например, при использовании Lubuntu подключаем поддержку LFCE:

sudo apt-get install x2golxdebindings

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

Установка клиента

Клиентское ПО X2Go для Windows, Linux и OS X можно скачать на сайте проекта. Большой минус — нет поддержки мобильных клиентов, при том что NoMachine поддерживает и Android и iOS. Но клиенты NoMachine с сервером X2Go несовместимы.

Если на локальном компьютере установлена Ubuntu, достаточно добавить пакет x2goclient:

sudo apt-get install x2goclient

А так выглядит клиент X2Go для Windows:

В случае если возникли проблемы с основным клиентом, написанным на Qt, можно использовать альтернативный клиент, написанный на wxPython.

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

Источник