Организуем себе безопасное рабочее место на удаленной виртуалке при помощи x2go
Достаточно давно я наткнулся на крайне интересную вещь — x2go.
По сути своей, это очередной способ поиметь себе remote desktop с linux-машины. Вот только в этот раз — способ достаточно шустрый, быстрый, работающий. А в нашем случае полезно ещё и то, что он туннелирует из коробки весь трафик через ssh.
В игры поиграть не получится, само собой, но вот Youtube я через него вполне себе смотрел )
Из приятных вкусностей — передача звука, принтеров, ресайз окна (если не используется родной системный X-сервер), наличие толкового клиента под windows, авторизация по ssh-ключам, возможность отключиться от сессии и оставить там всё запущенным. Традиционно, под виндой работает не всё (в частности, не удалось пошарить каталог и принтер), но в целом впечатления положительные. Можно комфортно работать на удаленном сервере в Голландии с машины в России.
Зачем это нужно, рассказывать, думаю, не нужно. Скажем так, для запуска Firefox с ботом для браузерной игры. Или для оплаты кредитками из недоверенной сети.
Собственно, покупаем любую виртуалку/делаем её сами в нормальной стране. Помним, что для нормальной работы Firefox/Iceweasel нужно от гигабайта RAM (иначе оно по OOM падать будет). Логинимся на неё по ssh, начинаем развлекаться.
Мануал актуален для текущих версий Ubuntu/Debian (debian 7+, ubuntu 12.04+) — соответственно, нужна виртуалка с ними. На OpenVZ из-за модуля ядра работать не будет, скорее всего.
Для начала создадим пользователя, под которым мы в дальнейшем будем использовать x2go:
# adduser username
По ходу дела у нас спросят 2 раза пароль, вводим какой-нибудь достаточно сложный. Остальное можно оставлять пустым.
Далее мы зашифруем домашний каталог пользователя. Ставим нужный софт:
# apt-get update; apt-get install ecryptfs-utils
Подгружаем модуль ядра для шифрования:
# modprobe ecryptfs
Чтобы он загружался при загрузке системы в файл /etc/modules нужно добавить строку:
Шифруем домашний каталог пользователя:
# ecryptfs-migrate-home -u username
Проверяем, что оно зашифровалось:
# ls /home/username
Access-Your-Private-Data.desktop README.txt
Логинимся нашим пользователем по ssh, проверяем, что он может корректно работать со своим домашним каталогом:
Если всё работает нормально, то запускаем команду:
$ ecryptfs-unwrap-passphrase
В ответ вам выдадут ключ, при помощи которого можно будет восстановить зашифрованные данные, если забудете основной пароль. Мне, в общем-то, ни разу не пригодилась =) Но если вы её решите записать — сделайте это на бумажку, которую будете хранить дома в столе без всяких комментариев на ней.
Помните, что файлы в домашнем каталоге будут доступны для чтения всем пользователям (особенно, руту), когда ваш пользователь залогинен в системе. Поэтому, если у вас есть причина шифровать домашний каталог — то делайте это всё же на виртуалке, к которой никто не имеет доступа кроме вас. К тому же, если вы положите в зашифрованный домашний каталог файлы (например, сайта), а потом выйдете из системы — то эти файлы перестанут быть доступны.
Ну, собственно, можно начинать ставить x2go. Сначала настраиваем сервер. Для начала напишу про Debian Wheezy. Создаём файл /etc/apt/sources.list.d/x2go.list с таким содержимым:
Добавляем ключ репозитория в систему:
# apt-key adv —recv-keys —keyserver keys.gnupg.net E1F958385BFE2B6E; apt-get update
Для убунты. Добавляем ppa x2go в систему:
# apt-get update; apt-get install python-software-properties; add-apt-repository ppa:x2go/stable; apt-get update
Ставим нужный софт для запуска удаленного рабочего стола. Я буду ставить xfce (он вполне неплохо работает удаленно), если у вас много экспы — ставьте что угодно. Главное, не Unity и не KDE (тормозит-с, ибо им видюха полноценная нужна).
# apt-get install x2goserver xfce4 xfce4-xkb-plugin
Для убунту лучше сразу сделать так:
# apt-get install x2goserver xubuntu-desktop
Ещё раз повторюсь, что ставить всё это на сервер, где крутится ещё что-то крайне не рекомендуется. Покушает много места и памяти.
В общем-то, сервер на этом готов. Ну можно поставить туда ещё firefox/iceweasel, если уже нет. Или jabber-клиент. Или skype-клиент (правда, голосом общаться не получится, наверное). Дальше ставим/настраиваем клиент.
Для винды нужно просто пойти сюда и ткнуть там ссылку «mswin», потом поставить клиент.
Для убунты 12.04+ и Debian 7+ можно воспользоваться командой (это уже на десктопе, если кто не понял):
# apt-get install x2goclient
Правда, из репозиториев приезжает достаточно старая версия (хотя и работающая), поэтому я рекомендую повторить на десктопе те же шаги, которые вы делали на сервере (создать файл /etc/apt/sources.list.d/x2go.list и так далее), только ставить один x2goclient, а не x2goserver.
Так же нужно знать, что на linux-ах x2goclient приносит за собой и запускает openssh-server. Он нужен для работы x2go, но ему не нужно слушать внешние интерфейсы (а в таком случае ssh-сервер будет недоступен всем остальным, кроме вас). Поэтому, перевесим его на localhost:
# sed ‘s/.*ListenAddress.*/ListenAddress 127.0.0.1/g’ /etc/ssh/sshd_config
# /etc/init.d/ssh restart
Теперь можно смело запускать x2go-клиент. В нём топаем в менюшку Session -> New Session.
Меняем значок на клевую картинку, создаём сессию для подключения.
В поле Host пишем ip-адрес или dns-имя нашего сервера.
В поле Пользователь — имя пользователя, которого мы создавали (и которому шифровали папку).
SSH порт — 22 стандартный, если меняли — сами знаете, что написать)
Если вы знаете про ssh-ключи, то я сильно рекомендую использовать для авторизации в x2go именно ключи (впрочем, пароль там сохранить негде, так что его не сопрут. Разве что кейлоггерами).
Тип сессии — XFCE, если вы ставили xfce. Если что-то другое — сами выберите нужное 😉
Далее переходим во вкладку Соединение. Там выбираем ADSL, метод сжатия 16m-jpeg, Качество — 9.
Во вкладке «Установки» выключаем звук и принтер (звук на арендованных виртуалках работать не будет, скорее всего), если они не нужны.
Экспорт каталогов — по вкусу.
Усё, жмем подключиться, вводим пароль от пользователя/ключа, наслаждаемся. Если просто закрыть окно x2go — то сессия останется висеть в фоне. Если явно нажать выход в XFCE — то сессия завершится. Только не забывайте, что если вы не завершите сессию, то файлы в домашнем каталоге останутся незашифрованными для рута.
После первого логина в XFCE нужно добавить несколько апплетов на панель (пкм по панели -> Panel -> add new item). Нужно добавить Actions buttons (чтобы можно было делать logout), и Keyboard layouts. В настройках последнего нужно будет настроить клавиши для переключения раскладки и добавить вторую раскладку, если нужна.
Ещё полезная фича для хомяков — запуск отдельного приложения по x2go. Выбираем тип сессии «Приложение», Команду/исполняемый файл и логинимся. Такие приложения выглядят под убунтой достаточно нативно (особенно если настроить внешний вид на стороне сервера), вот только при запуске браузера таким способом у меня иксы упали =) Остальное запустилось нормально.
Настройка SSH аутентификации по ключам в Windows 10 / 2019
В этой статье мы настроим SSH аутентификацию в Windows по RSA-ключам для безопасного доступа к удаленным системам. Мы покажем, как сгенерировать RSA-ключи (сертификаты) в Windows и настроить сервер OpenSSH в Windows 10/Windows Server 2019 для авторизации по ключам (без паролей).
Аутентификация по в SSH ключам широко используется в мире Linux, а в Windows этот функционал появился относительно недавно. Идея заключается в том, что на SSH сервере добавляется открытый ключ клиента и при подключении сервер проверяет наличие соответствующего закрытого ключа у клиента.
Генерация RSA ключей на клиенте Windows
На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару RSA-ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ помещается на SSH сервер в файл authorized_keys. Чтобы на клиенте Windows сгенерировать RSA ключи, вы должны установить клиент OpenSSH.
В Windows 10 1809 и Windows Server 2019 клиент OpenSSH устанавливается как отдельный встроенный компонент:
Add-WindowsCapability -Online -Name OpenSSH.Client
Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:
Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).
Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:
- id_rsa – закрытый ключ
- id_rsa.pub – публичный ключ
После того, как ключи созданы, вы можете добавить закрытый ключ в службу SSH Agent, которая позволяет удобно управлять закрытыми ключами и использовать их для аутентификации.
SSH Agent может хранить закрытые ключи и предоставлять их в контексте безопасности текущего пользователя. Запустите службу ssh-agent и настройте автоматический запуск с помощью PowerShell команд управления службами:
set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent
Добавьте ваш закрытый ключ в базу ssh-agent:
Настройка OpenSSH в Windows для авторизации по ключам
Теперь открытый ключ, который вы сгенерировали на клиенте, нужно скопировать на ваш SSH сервер (в этом примере это удаленный компьютер с Windows 10 1903 и настроенной службой OpenSSH).
Скопируйте файл id_rsa.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 10 создан пользователь admin, значит я должен скопировать ключ в файл C:\Users\admin\.ssh\authorized_keys.
Можно скопировать ключ на SSH сервер с клиента с помощью SCP:
scp C:\Users\youruser\.ssh\id_rsa.pub admin@192.168.1.90:c:\users\admin\.ssh\authorized_keys
Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.
Для подключения через SSH к удаленному хосту используется следующая команда:
ssh (username)@(имя или IP адрес SSH сервера)
Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.
ssh admin@192.168.1.90 -i «C:\Users\youruser\.ssh\id_rsa»
Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.
Вход по SSH ключу для локальных администраторов Windows
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).
Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH («C:\ProgramData\ssh\sshd_config«).
Дополнительно в файле sshd_config вы можете разрешить вход по RSA ключам:
И запретить доступ по паролю:
После сохранения изменений в файле sshd_config не забудьте перезапустить службу sshd.
Еще один небольшой нюанс. В старых версиях OpenSSH нужно было предоставить права службе NT Service\sshd на чтение ключа authorized_keys.
Для этого нужно выполнить одно из следующих действий:
- Установить модуль OpenSSHUtils: Install-Module -Force OpenSSHUtils -Scope AllUsers . Для изменения прав на файл нужно выполнить команду: Repair-AuthorizedKeyPermission -FilePath C:\Users\admin\.ssh\authorized_keys ;
- Измените NTFS права на файл с помощью модуля NTFSSecurity или icacls;
- Либо вы можете в конфигурационном файле sshd_config отключить режим StrictModes. По умолчанию этот режим включен и запрещает аутентификацию по ключам, если закрытый и открытый ключ недостаточно защищены. Раскомментируйте строку #StrictModes yes , измените на StrictModes no .
Итак, вы настроили SSH аутентификацию в Windows по открытому RSA-ключу (сертификату). Теперь вы можете использовать такой способ аутентификации для безопасного доступа к удаленным северам, автоматического поднятия проброса портов в SSH туннеле, запуска скриптов и других задачах автоматизации.
Спасибо! Первая рабочая статья -_ stackoverflow.com уже весь на эту тему перечитал).
debug1: Found key in C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/known_hosts:9
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa (000002372A7B17D0), agent
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ed25519 (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_xmss (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:5U76PQzmZJ7xce9TDvyt1P/sqNCX/GHOZSLk3TR3x1o C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa
Можете подсказать что не так?
Какую команду используете для SSH подключения? Ключ добавлен в ssh-agent?
Попробуйте указать путь к вашему файлу с закрытым ключом вручную:
ssh root@192.168.1.90 -i «C:\Users\user1\.ssh\id_rsa»
При генерации ключа не нашел файлы в профиле пользователя. Они были в «C:\Windows\System32»
Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32
А как это работает, если сервер на Linux, а клиент на Windows?
Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)