Переход с Royal TS на Remote Desktop Manager: 1 243 подключения и вход по аппаратному сертификату

Мы перенесли всю рабочую базу подключений с Royal TS на Remote Desktop Manager. Причина не в интерфейсе: мы переводили доступ ко всем машинам на аппаратные сертификаты с YubiKey, а SSH-движок Royal TS сертификаты OpenSSH не поддерживает — по-другому этот вход было не сделать. Заодно получили один клиент на все протоколы, единый вход через jump-host и базу из 1 823 записей, перенесённую без ручного перебивания и без потерь.

Как устроен доступ

1. Один клиент — все протоколы. SSH, RDP, веб-интерфейсы и VNC живут в одном дереве подключений, а не в разных инструментах.
2. Единый вход — через SSH jump-host. Все подключения идут через единый jump-host (ProxyJump). Прямых путей в обход него нет; сертификат целевые узлы вообще не примут напрямую с рабочей станции — только с jump-host.
3. Аутентификация — сертификатом с YubiKey. Ключ не покидает токен (FIDO2), на каждый вход — касание ключа. Без ключа с токена сертификат бесполезен. Короткий срок жизни решает другую задачу: при увольнении достаточно убрать человека из группы каталога, а сертификат истечёт сам через несколько дней — отзыв и списки отзыва не нужны.
4. Тоннели для RDP и веба, натив для SSH. RDP и веб идут через SSH-тоннель (динамический порт), SSH-шеллы — через нативный SSH-переход RDM. Каждый тоннель на своём локальном адресе, чтобы сохранённые логины не перезаписывали друг друга.
5. Сетевое железо — через тот же jump-host. Коммутаторы и роутеры живут в том же дереве и доступны только через jump-host — отдельного пути к ним нет.

Задача

Мы меняли не инструмент, а модель доступа. Новая модель — только личные аппаратные сертификаты: ключ на YubiKey (FIDO2), короткоживущие сертификаты OpenSSH, единый jump-host, ни одного приватного ключа на диске и ни одного пароля от Linux-серверов.

Royal TS такую модель не тянет — и это не вопрос настроек.

• Встроенный SSH-движок Royal (Rebex) не поддерживает сертификаты OpenSSH. Он умеет предъявить серверу голый ключ, но не пару «ключ + сертификат», которую требует наш SSH.
• Обходной путь через PuTTY-плагин требует ключ в файле .ppk — то есть приватный ключ на диске. Это ровно то, от чего мы уходили: смысл аппаратного токена в том, что ключ из него не извлекается.

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

Главное условие — перенести всё и ничего не потерять. База — 1 823 записи: подключения, дерево папок и тоннели, с инвентарём, адресами и схемой переходов через jump-host. Перебивать руками нельзя; структуру и имена нужно сохранить один в один.

Отдельная сложность: штатный экспорт Royal при импорте в RDM срезает всю аутентификацию и цепочку переходов. У сотен SSH-записей терялась привязка к jump-host, а все 34 тоннеля приходили с одним и тем же локальным адресом — гарантированная путаница сохранённых логинов. Переносить «один в один» было нельзя: топологию берём из экспорта, а доступ собираем заново.

Что сделали

• Собрали дерево генератором, а не мышкой. Скрипт читает экспорт Royal, берёт из него топологию (кто через какие переходы идёт, адреса, порты, инвентарь, схему «один хоп / два хопа») и строит базу RDM с сохранением имён и структуры папок. Правки вносятся в генератор и прогоняются заново — воспроизводимо, а не вручную по тысяче записей.

• Настроили вход по FIDO2-сертификату. Запись SSH-ключа хранит «ручку» ключа с токена и файл сертификата; SSH-агент везде выключен — RDM работает с YubiKey напрямую. Поддержка сертификатов для sk-ключей появилась в RDM только в свежих версиях — на них мы и строили.

• Ввели единый jump-host и шлюзы площадок. Jump-host наследуется на всё дерево; для площадок с закрытой сетью добавлен второй хоп через шлюз площадки — её роутер (jump-host → шлюз площадки → узел).

• Развели RDP и веб по тоннелям с уникальными адресами. Исправили артефакт импорта: вместо одного общего локального адреса на все 34 тоннеля — свой адрес каждому, чтобы сохранённые логины не затирались. Общий тоннель держится, пока открыта хоть одна сессия (VPN group), и закрывается только с последней.

• Разделили доступ по типам узлов. Linux-серверы — по сертификату; сетевое железо — своим способом входа, но тем же путём: только через jump-host.

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

Результат

Одна база, один клиент на все протоколы

Тип подключения	В рабочей базе RDM
SSH-шелл	682
RDP	239
Веб-интерфейсы	156
VNC	126
Прочие	40
Итого подключений	1 243
SSH-тоннели	34
Папок в дереве	447

Исходные 1 823 записи Royal (подключения, папки, тоннели) перенесены в единое дерево RDM с сохранением имён и структуры; дубликаты, времянки и шаблоны (около сотни «несортированных») отсеяны на ручном разборе, а не затянуты вслепую.

Доступ к машинам

	было (Royal TS)	стало (RDM)
Вход по аппаратному сертификату	невозможен (движок не умеет)	FIDO2 + сертификат OpenSSH
Приватные ключи на диске	требовались (.ppk)	нет — ключ не покидает YubiKey
Пароли от Linux-серверов	хранились в записях	нет — только сертификат
Срок жизни доступа	ключ живёт, пока не отзовут	короткоживущий сертификат
Путь до узла	разрозненно	только через единый jump-host

Итог по сути задачи: вход, которого в Royal не существовало, работает от края до края — касание YubiKey, проход через jump-host, сертификат на целевом узле. На дисках рабочих станций больше нет ни приватных ключей, ни паролей от Linux-серверов; доступ дополнительно ограничен членством в группе каталога, так что валидный сертификат сам по себе двери не открывает.

Что мы вынесли из этой работы

1. Сертификат нельзя «подложить» сторонней программой. Соединение аутентифицирует тот, кто его открывает, поэтому всё решает SSH-движок самого клиента. Royal здесь упирается в архитектуру, а не в галочку в настройках — это и есть причина перехода.

2. Топологию переносим из экспорта, аутентификацию — собираем заново. Импорт чужого формата предсказуемо теряет привязку к jump-host и ключам; рассчитывать на перенос «один в один» нельзя.

3. Тысячу однотипных записей строит генератор, а не рука. Единичная правка проходит по всей базе одним прогоном и не оставляет полузабытых исключений.

Чем можем помочь

Если вы держите парк подключений в Royal TS, mRemoteNG или разрозненных клиентах и упираетесь в вход по сертификату, единый jump-host или просто в ручную поддержку сотен записей — это ровно наша работа.

Берёмся за:

• аудит текущей базы подключений — что переносится как есть, что придётся пересобрать, где спрятаны пароли и ключи на дисках;
• переход на Remote Desktop Manager с сохранением дерева и имён, без ручного перебивания — генератором из вашего экспорта;
• вход по аппаратным сертификатам (FIDO2/YubiKey, OpenSSH-сертификаты) вместо ключей и паролей, с коротким сроком жизни доступа;
• единый jump-host и схему двух хопов для площадок с закрытыми сетями (ProxyJump, тоннели RDP и веба);
• модель доступа для команды — у каждого свой ключ на токене, доступ выдаётся и снимается группой каталога.