SSH +reverse https proxy, при чём тут openSSL(VPN)?

Question

[Quqas]

Хочу по ssh подключится(извне) к консоле устройства. лишь для того чтобы управлять. а не для того чтоб трафик гонять

условия: доступ извне только https трафику, не 443 порт only, а именно https.

в гуглах пишут ничего страшного
настраиваете reverse proxy и вперёд
ssh -o ProxyCommand="openssl s_client ***
но в тех же "советах" ни слова об настройке на ssh серваке
не понимаю sshd by default понимает https? или именно ssh траф лезет но тогда как nginx его направляет?
ну и причём тут openssl? опять же ни слова про его настройку на ssh серваке - а якобы он должен этот коннект схавать

я могу "свой" reverse proxy настроить. но ограниченно. только внутренний ip/порт и выбор https|http (http или https "внутри" правильней выбирать, под задачу? )

"извне" только выбор sni в запросе.

ну и не выходит ничего "по советам"

хотя м.б. я не так делаю

ssh -o ProxyCommand="openssl s_client -connect your_domain.com:443 -servername your_domain.com"

это часть очевидно

неясно что дальше добавить?

root@192.168.5.1 -p 222
или же root@your_domain.com -p 443

и так и сяк ноль успеха

Comments

[Dmitry]

это какой то поток сознания.
ты чего добиться-то хочешь? какая задача?

[Quqas]

Dmitry, по ssh к серваку подключиться
извне

[AlexVWill]

Грамотно поставленный вопрос - половина ответа. Если ты хочешь, чтобы кто-то добровольно потрадил время на ответ, не заставляй людей тратить ещё больше времени, чтобы понять всю ту белиберду, что ты написал. Напиши четко и понятно суть того, что надо сделать, и по какой причине не работает, самоё главное чем именно установлено ограничение. И при чем тут OpenVPN?

[VoidVolker]

Quqas, и? При чём тут обратный HTTPS прокси? Вам нужен тунель/обратный тунель для трафика? Будьте любезны собраться с мыслями и сформулировать вашу задачу более конкретно - что у вас есть и что именно вы хотите получить в итоге. Как правильно задавать вопросы: bugtraq.ru/forum/faq/general/smart-questions.html

[Quqas]

обновил

как можно сделать ещё понятней вам не понимаю сам

[AlexVWill]

Quqas, плохо старался...
Если по теме, то если доступен только Https трафик (непонятно зачем и как, ну допустим...), то реверс прокси тебе не поможет. Ибо он просто переадресует трафик на нужный адрес:порт, а не переводит трафик из протокола в протокол, из Https в SSH. Или ты не понимаешь, что делаешь, или ты не понимаешь суть твоей проблемы. Или все вместе (что более вероятно).
Вообще, для этого реверс прокси не нужен от слова совсем, у тебя же нет ограничений по маршрутам и нет задачи переадресации. Для чего ты его пытаешься прикрутить?

[Valentin Barbolin]

https://github.com/tsl0922/ttyd ?

[Quqas]

AlexVWill,

а не переводит трафик из протокола в протокол, из Https в SSH

именно
поэтому советы (а их в гугле не 1 и не 2 и разные люди =не копипаста) и вызывают вопросы и удивление.

но как я понял именно часть команды про openssl превращает ssh в https

Answer 1

[Vindicar]

Ну для начала, OpenSSL - это (если на пальцах) библиотека+утилита для шифрования трафика. Ею или её аналогами пользуется примерно всё, что хочет установить шифрованный канал. Помимо использования её как библиотеки, ты можешь использовать её как утилиту, в духе "слушай адрес+порт A.B.C.D:X, все входящие подключения расшифровывай(для сервера)/шифруй(для клиента), после чего перенаправляй на адрес+порт E.F.G.H:Y". Тогда таким образом можно создать шифрованный туннель, через который пускать трафик какого-то другого приложения.

Но постановка задачи вызывает вопросы. Что значит "только по HTTPS"? Каким именно образом это правило контролируется? Не зная ответа на этот вопрос, решения не найдёшь.

Если "нужно увидеть TLS-хэндшейк", то да, подход на базе OpenSSL может сработать, но его нужно будет настроить и на сервере, и на клиенте. На сервере - OpenSSL должна слушать порт и перенаправлять расшифрованные соединения на порт SSH сервера. На клиенте - OpenSSL должна слушать порт, и пробрасывать зашифрованные соединения на адрес+порт, который случает OpenSSL на сервере.

Но имей ввиду, что SSH сервера вроде OpenSSH (но вроде не Dropbear) и так используют OpenSSL для защиты своего трафика. Хотя при этом всё равно есть различия между тем, как устанавливается соединение при HTTP+TLS и при SSH, так что может в таком туннеле и будет смысл.

Но соответствие HTTPS может контролироваться более жёстко. Нужно использовать заданный хостером HTTP-прокси/реверс-прокси для работы с сетью? Или, скажем, слишком долго висящие соединения принудительно рвутся? Или TLS-хэндшейк проверяется на соответствие популярным браузерам? Во всех этих случаях простым туннелем ты не обойдёшься.

Comments

[Quqas]

Что значит "только по HTTPS"?
Но соответствие HTTPS может контролироваться более жёстко. Нужно использовать заданный хостером HTTP-прокси/реверс-прокси для работы с сетью? Или, скажем, слишком долго висящие соединения принудительно рвутся? Или TLS-хэндшейк проверяется на соответствие популярным браузерам? Во всех этих случаях простым туннелем ты не обойдёшься.

встроенный в кинетик http туннель ихней облачной службы
заведомо известно что если просто tcp поток то не летит
сам tls client hello отслеживают чётко
какое sni туда и попадает на внутренний адрес\порт
и если на адресе-порте web всё ок
а с ssh неясно. заведомо не веб

openssl отдельно по sni как-будто попадает куда надо(т.е. на порт ssh), но не держит туннель - данных то нету+непонимаю с чего вдруг ssh сервер должен этот openssl понимать? я его не настраивал. и в примерах\советах тоже никто не настраивает а якобы сразу соединяются

вся "надежда" что я не так пишу команду

[Vindicar]

Quqas, во, это стоило в вопрос написать.
ssh сервер зависит от реализации - некоторые используют OpenSSH для шифрования. Но толку от этого не будет, так как получится, что от клиента поступает трафик, "обёрнутый в два слоя", а сервер снимает только один слой.
Так что нужно будет что-то на обоих концах. Есть возможность при загрузке запустить на роутере openssl с серверным настройками?

[Quqas]

Vindicar, надо ковырять... и смотреть, может и можно отдельный порт с openssl сервером прикрутить. но точно что сам opensll ещё надо както туда поставить....

т.е. в примерах из которых я подчерпнул метод - все эти советчики не говорили что у них сервер debian и поэтому ихний ssh из коробки понимал что делать когда на ssh порт долбится openssl?

[Vindicar]

Quqas, ну я фз что это за примеры.

Но вообще-то тут нужно понимать, как работает опция ProxyCommand. Я это понимаю таким образом:
Обычно SSH-клиент устанавливает сетевое соединение, производит handshake (договаривается с сервером о ключе, алгоритме шифрования, убеждается, что сервер тот, за кого себя выдаёт, и т.п.), потом организует шифрованный канал и начинает рабочую сессию.
Если используется опция ProxyCommand, то вместо установки сетевого соединения SSH-клиент выполняет указанную команду, и использует её пару stdin-stdout в качестве сетевого соединения. Далее всё то же самое: handshake, шифрованный канал, рабочая сессия.

Т.е. чтобы приведённый пример работал, нужно чтобы на целевом сервере на 443 порту крутился какой-то реверс-прокси (точнее, TLS termination proxy), который распакует трафик из туннеля и пробросит его на порт, который слушает SSH-сервер. Имхо, SSH-сервер про эти фокусы вообще ничего не знает.

[Quqas]

Т.е. чтобы приведённый пример работал, нужно чтобы на целевом сервере на 443 порту крутился какой-то реверс-прокси (точнее, TLS termination proxy), который распакует трафик из туннеля и пробросит его на порт, который слушает SSH-сервер. Имхо, SSH-сервер про эти фокусы вообще ничего не знает.

это выполняется
reverse proxy настроен
слушает 443 и направляет на 222

но вот на счёт что "распаковывает" не уверен и наоборот имхо вредно, либо ещё один прокси нужен? помимо внешнего ещё и внутренний?

советы(читал и больше)
https://dev.to/udara_dananjaya/how-to-access-ssh-o...

https://iyzico.engineering/proxy-ssh-using-tls-sni...

[Quqas]

нигде в советах про ковыряние на стороне ssh сервера ни слова

Answer 2

[rPman]

Если вам нужно обеспечить доступ к сервису в локальной сети по http извне, но защитить трафик каким-либо шифрованием, то более чем достаточно обычного перенаправления портов ssh, на роутере или на машине в локальной сети запускаем ssh сервер с разрешенным перенаправлением портов (по умолчанию это разрешено AllowTcpForwarding Yes), а затем в сети, откуда необходим доступ, нужно запустить:

ssh user@host -L ip_адрес_локальной_машины:port_локальной_машины:ip_адрес_машины_с_http_сервисом:port_этого_сервиса

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

ssh user@host -R ip_адрес_в_локальной_сети_целевого_сервиса:port_целевого_сервиса:ip_адрес_в_локальной_сети_клиента:port_в_локальной_сети_клиента

в обоих случаях сервис станет доступен из локальной сети клиента по адресу: http://ip_адрес_в_локальной_сети_клиента:port_в_ло...

Точнее по тому же протоколу, по которому он работает в этой локальной сети.

ip_адрес_в_локальной_сети можно не указывать, если он 127.0.0.1, так же порт по которому ssh будет слушать подключение, если будет ниже 4000 то ssh должен быть запущен под root

upd. если нужно именно https протокол, то нужно запускать http сервер с поддержкой ssl сертификатов (обычно в роутерах этого нет) в режиме проксирования (например nginx)

Comments

[Vindicar]

Нейронка не поняла вопроса в посте.

[rPman]

Vindicar, я человек, когда пользуюсь нейронкой я так и говорю

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