Python-сообщество

Всем привет!

Возникла потребность встроить в производственный портал возможность подключения к удаленным пользователям по SSH. Удаленные тонкие клиенты крутятся на Linux, на котором поднят сервер openssh.

Портал предоставляет список пользователей, где напротив каждого пользователя будет своего рода button для подключения по SSH во всплывающем окне на самом портале. Это пока что образное описание

Выбор пал на готовый продукт с открытым исходным кодом - webssh.

На github проект собирается в docker, пробрасывается http протокол по 8888 порту. Собственно, через браузер имею доступ к вьюхе и могу подсоединиться к нужному мне пользователю.

Вся задача заключается в том, чтобы вместо предоставленной вьюхи выводить контент соединения в своём фрейме.

Если я правильно понимаю, то webssh сам является и веб-сервером (который генерирует саму страничку) и прокси.

Возможно ли отделить прокси-сервер в отдельный контейнер (подобию тому, как сделали noVNC, вынесших websockify в отдельный проект), и отдельно запускать свою веб-страницу с переданными под капотом данными авторизации?

Может есть у кого какие идеи или примеры встраивания?

P.S. Удалось подобным методом встроить noVNC. Имею пример, поэтому, хотелось бы так же встроить webssh.

alexanderzhirov
Имею пример, поэтому, хотелось бы так же встроить webssh.

А почему именно webssh?
Человек там сделал какой-нибудь внутренний API между tornado и paramiko? Нет, же. Придётся это всё разбирать обратно, а потом ещё и в JavaScript-части разбираться, чтобы понять, где у него швы проходят между частями внутри программы и как отодрать одно от другого. Что-то с модульностью программы у него не то, нет чётких интерфейсов у модулей. Понимаешь, да, программа должна представлять из себя набор модулей с чёткими интерфейсами. Это нужно для того, чтобы вот так вот можно было отделять части программы друг от друга так, как тебе сейчас надо отделить.
Поэтому ты и не видишь, как её можно переделать.

Представь просто, что ты едешь на машине, у тебя прокалывается колесо, ты выходишь и думаешь о том, чтобы снять проколотое колесо, взять целое колесо из багажника, поставить целое колесо, а проколотое в багажник положить и поехать дальше. Делов на десять минут. Тут ты смотришь, а там не болты, которые можно открутить, а просто слизь из масла, клея и сваренных штырей, и всё вместе это держит это пробитое колесо плотно к машине. Вроде приделано хорошо, не оторвёшь, но поменять-то его надо. И вот у тебя возникают вопросы к тому, кто это устанавливал. И ехать ты не можешь, потому что стоишь и кубатуришь только “как это колесо поменять-то?”.

Если бы мне нужен был SSH-клиент в веб-интерфейсе, я бы эту говняшку не стал бы брать. Она только для себя самой сделана.

Как видишь эти вопросы ему уже задавались
https://github.com/huashengdun/webssh/issues/294
https://github.com/huashengdun/webssh/issues/227
Ноль внимания.
Конечно! Как он переделает свою прогу, если он изначально с умным видом заложил в неё множественное наследование с использованием миксинов, а вот просто переделать её на внутренние апишки, чтобы можно было в любой момент банально морду её поменять на что угодно, - это не, это ему сложно.

Так что забей на эту херню, он тебе не ответит.

Отредактировано py.user.next (Дек. 9, 2022 11:27:45)

py.user.next
Так что забей на эту херню, он тебе не ответит.

Да я уже это и так понял… Решил вот спросить на форуме, может кто накрутил самопально. Так-то можно через get в соседнем контейнере открывать соединение, но не то, что хотелось бы.

Есть ли какие грамотные предложения по подобного рода интеграциям? Я пока не сталкивался с фронтендом, совсем всё жутко со всеми этими скриптами для меня.

Вообще, там три части должно быть.

1. Ядро с API в HTTP-протоколе, которому можно ставить задачи.
2. Манипулятор в виде JavaScript-функций для управления ядром из пункта 1.
3. Страничка в HTML для соединения пользователя и манипулятора из пункта 2.

Пользователь обращается к страничке и через неё посылает задачу манипулятору. Манипулятор берёт задачу от пользователя, переводит её в задачу ядру и посылает эту задачу ядру через API. Ядро отвечает манипулятору на задачу от манипулятора, а манипулятор отвечает пользователю на задачу от пользователя.

Сессии сохраняются ядром где-нибудь там внутрях. Это инкапсулировано в области видимости ядра по принципу чёрного ящика.

alexanderzhirov
Я пока не сталкивался с фронтендом

Это не фронтенд.

py.user.next
Вообще, там три части должно быть.

1. Ядро с API в HTTP-протоколе, которому можно ставить задачи.
2. Манипулятор в виде JavaScript-функций для управления ядром из пункта 1.
3. Страничка в HTML для соединения пользователя и манипулятора из пункта 2.

Благодарю. Буду что нибудь гуглить…