forum.opennet.ru - "Раздел полезных советов: Организация доступа к SSH и HTTPS ч..." (42)

"Раздел полезных советов: Организация доступа к SSH и HTTPS ч..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Организация доступа к SSH и HTTPS ч..."	+1 +/–
Сообщение от auto_tips (?), 25-Июл-18, 10:37
В nginx 1.15.2 в модуль ngx_stream_ssl_preread была добавлена переменная $ssl_preread_protocol, которая определяет наибольшую версию протокола SSL/TLS, которую поддерживает клиент. При помощи новой переменной можно создавать конфигурации для доступа с использованием различных протоколов через один сетевой порт при проксировании трафика с использованием модулей http и stream. В частности, можно разделять обработчики для трафика на базе SSL и не использующего SSL (например, SSH). Для организации доступа по SSH и HTTPS через один сетевой порт 443 можно по умолчанию пробрасывать трафик на SSH, а если определена версия протокола TLSv1.2 пробрасывать на HTTPS: stream { upstream ssh { server 192.0.2.1:22; } upstream web { server 192.0.2.2:443; } map $ssl_preread_protocol $upstream { default ssh; "TLSv1.2" web; } # SSH и SSL на одном порту server { listen 443; proxy_pass $upstream; ssl_preread on; } } По аналогии можно настроить проброс через один сетевой порт для любых других сочетаний SSL/не-SSL протоколов, например, "HTTP/HTTPS", "TCP DNS/DNS over TLS" и т.п. URL: https://www.nginx.com/blog/running-non-ssl-protocols-over-ss.../ Обсуждается: http://www.opennet.me/tips/info/3071.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Google SSH HTTPS multiplexing , Анонисмус (?), 10:37 , 25-Июл-18, (1) +1
но зачем 8-O, троллейбусизбуханки (?), 10:01 , 26-Июл-18, (2)

Например, чтобы пролезть оттуда, где вовне открыт доступ только на 80 и 443, на , Crazy Alex (ok), 15:17 , 28-Июл-18, (5)

а тебе не ссыкотно обычно где вовне он так открыт - еще при входе заставляют под, толлейбусизбуханки (?), 18:50 , 29-Июл-18, (6) –1

Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, ба, Crazy Alex (ok), 14:24 , 31-Июл-18, (15)

и твоя стандартная подпись под ней Ну и оно вот тебе - надо потом начальству по, пох (?), 22:21 , 31-Июл-18, (17)

Да никто не заставляет мобилы сдавать Речь об обычных больших айтишных конторах, Crazy Alex (ok), 11:50 , 04-Авг-18, (26)
А вы не думали что есть юзкейсы кроме того что ты раб который пyкнуть боится что, Аноним (36), 00:56 , 12-Сен-18, (36) +1
Ну и страдай, трепеща перед начальством и подписывая разрешения на каждый похо, Максим (??), 22:21 , 20-Сен-18, (38)

Туда всякие поцреоты идут , Full Master (?), 19:46 , 26-Мрт-21, (42)

почему нельзя просто на свой vds повесить sshd на 443 порт , atk91 (ok), 13:36 , 06-Сен-18, (33)

А вдруг там уже сайтик висит имени Васи Пупкина , lv333 (ok), 21:26 , 22-Сен-18, (39)

А есть ли возможность сделать подобное с витруальными-хостами server_name , Василий (??), 12:58 , 26-Июл-18, (3)

Ага , вот тут наспиано как это сделать http nginx org en docs stream ngx_strea, Василий (??), 13:04 , 26-Июл-18, (4)

нельзя, нет в ssh никакого server name , толлейбусизбуханки (?), 18:54 , 29-Июл-18, (8)

нет да и зачем для этого есть sni, который прекрасно работает без этих ненужно-, толлейбусизбуханки (?), 18:53 , 29-Июл-18, (7)

Это получается, что если долбиться в 443 порт как SSL 2,3 , TLS 1 0,1 1 или л, adsh (ok), 19:43 , 30-Июл-18, (9)

Если вашему sshd поплохеет из-за того, что ему от неаутентифицированного клиента, Аноним (10), 21:00 , 30-Июл-18, (10) –1

Обычное количество HTTP запросов не идёт ни в какое сравнение с числом таковых ж, adsh (ok), 22:02 , 30-Июл-18, (11) +1

а они не могут Там суть не в по умолчанию а в нешмалга я распознать то есть, толлейбусизбуханки (?), 12:09 , 31-Июл-18, (14) +1

да не переживайте так, васян-vds у на котором этот конфиг бездумно скопипастили,, толлейбусизбуханки (?), 12:04 , 31-Июл-18, (13)
Ну ты же умнее автора примера, небось сообразишь как остальные версии прописать , Аноним (36), 00:45 , 12-Сен-18, (34)

Так, а для чего это делать Не, серьезно -- для чего , int13h (ok), 22:26 , 30-Июл-18, (12) +2

security by obscurity, Аноним (16), 18:02 , 31-Июл-18, (16)

Коллега, неопытный администратор, которому кто-то выслал доступ к серверу в виде, int13h (ok), 23:54 , 31-Июл-18, (18) +1

Порт может быть закрыт, а ключ можно украсть вместе с компом Паролить ключ - эт, adsh (ok), 00:39 , 01-Авг-18, (19)

Откройте порт -- в чем проблема Ну, если есть сложности с запоминанием пароля , int13h (ok), 00:49 , 01-Авг-18, (20)

Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только, adsh (ok), 01:21 , 01-Авг-18, (21)

Мы говорим о хостинге или сервере аппаратном, виртуализированном Если о хости, int13h (ok), 09:43 , 01-Авг-18, (23)

Вообще говоря - нужно спросить у автора, для какого случая это всё Это может быт, adsh (ok), 15:17 , 01-Авг-18, (25)

Вас обманули Пасс-фраза вводится один раз при авторизации в системе, опциональн, ssh (ok), 09:37 , 01-Авг-18, (22)

Вы сами себя обманули Это от клиента зависит, как он работает с паролем к ключу, adsh (ok), 15:12 , 01-Авг-18, (24)

От наличия и настроек ssh-agent, если уж так говорить , h31 (ok), 12:37 , 04-Авг-18, (27)
Разумеется я имел ввиду клиент из комплекта OpenSSH, там именно так как я написа, ssh (ok), 14:48 , 07-Авг-18, (29)

И nginx не рестартанул, а остался работать со старым конфигом, так как именно та, Аноним (28), 23:00 , 05-Авг-18, (28)

омг, restart reload вы описали поведение для reload а, а при restart е выполн, Аноним (30), 10:00 , 22-Авг-18, (30)

Зависит от ОС В нормальных - при restart е перед стопом делается nginx -t , moo (?), 09:08 , 04-Сен-18, (31)

https i imgur com 7hWAYId pngда, все получилось, nssnnssn (?), 18:36 , 20-Сен-18, (37)

А почему нет-то Мало ли откуда приспичит до сервера достучаться, и может там вс, Аноним (36), 00:47 , 12-Сен-18, (35)

https github com google huproxy, Google (?), 17:56 , 04-Сен-18, (32)
Есть же sslh для этого , Имя (?), 11:12 , 31-Окт-18, (40)
А как быть в ситуации если есть сервак с белым IP, а на нем 10 вируталок с сервм, Nolf (ok), 17:46 , 13-Мрт-19, (41)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Анонисмус (?), 25-Июл-18, 10:37 +1 +/–

Google: "SSH HTTPS multiplexing"

Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от троллейбусизбуханки (?), 26-Июл-18, 10:01 +/–

но зачем? 8-O

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

3. Сообщение от Василий (??), 26-Июл-18, 12:58 +/–

А есть ли возможность сделать подобное с витруальными-хостами ( server_name  )?  Например крутятся во многих lxc разные сайты и мы хотим давать доступ и по https и по ssh через единый nginx на хост системе

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #7

4. Сообщение от Василий (??), 26-Июл-18, 13:04 +/–

Ага , вот тут наспиано как это сделать
http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_modul...
как я понял , можно написать еще один map по ssl_preread_server_name

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8

5. Сообщение от Crazy Alex (ok), 28-Июл-18, 15:17 +/–

Например, чтобы пролезть оттуда, где вовне открыт доступ только на 80 и 443, на свой VDS

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #6, #33

6. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:50 –1 +/–

а тебе не ссыкотно?
обычно где вовне он так открыт - еще при входе заставляют подписать бумажку, что на работе надо заниматься работой, а не по своим vds лазать. И учти, что pa/checkpoint/cisco умеют отличать ssl от левого протокола на тех же портах, тем же самым (и не только) способом.
впрочем, гораздо чаще - на дороге стоит дешифрующий прокси, и никакой ssh через него не пролезет в принципе.
а вот мобилы заставляют сдавать в камеру хранения гораздо позже.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15

7. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:53 +/–

> А есть ли возможность сделать подобное с витруальными-хостами ( server_name  )?
нет. да и зачем?
>  Например крутятся во многих lxc разные сайты и мы хотим
для этого есть sni, который прекрасно работает без этих ненужно-фокусов.
> давать доступ и по https и по ssh через единый nginx
а для ssh нет sni, да и не парсит его nginx, просто откидывая как "не-ssl" - поэтому попасть по ssh ты сможешь только на кого-то одного. Например на саму хост-систему, было бы чего ради огород-то городить...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

8. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:54 +/–

> как я понял , можно написать еще один map по ssl_preread_server_name
нельзя, нет в ssh никакого "server name".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

9. Сообщение от adsh (ok), 30-Июл-18, 19:43 +/–

Это получается, что если долбиться в 443 порт как SSL (2,3), TLS (1.0,1.1) или любым другим, не TLS 1.2 образом, то всё это будет скормлено sshd? А ему не поплохеет? Молодцы...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #13, #34

10. Сообщение от Аноним (10), 30-Июл-18, 21:00 –1 +/–

Если вашему sshd поплохеет из-за того, что ему от неаутентифицированного клиента прилетит в сокет мусор, то у вас какой-то неправильный sshd.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от adsh (ok), 30-Июл-18, 22:02 +1 +/–

Обычное количество HTTP запросов не идёт ни в какое сравнение с числом таковых же по SSH. Фактически, в статье описан рецепт, как сделать DOS на свой же сервер. Правильнее было сделать наоборот - воспринимать все обращения по умолчанию, как HTTP запросы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #14

12. Сообщение от int13h (ok), 30-Июл-18, 22:26 +2 +/–

Так, а для чего это делать? Не, серьезно -- для чего?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #35

13. Сообщение от толлейбусизбуханки (?), 31-Июл-18, 12:04 +/–

да не переживайте так, васян-vds'у на котором этот конфиг бездумно скопипастили, чтобы "обойти систему", в общем-то пофиг. В том числе и тот факт, что пользователи неправильных браузеров сайта не увидят.
а реальные применения препарсера - они для ids каких-нибудь имеют смысл, защит от атак ("ssl2 роняем на пол, это точно не человек, странные протоколы отправляем в один балансер, нормальные, реально используемые большинством юзеров - в другой"), еще чего в этом же роде - и там, уверяю, не ssh будет принимать default ;-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

14. Сообщение от толлейбусизбуханки (?), 31-Июл-18, 12:09 +1 +/–

> Правильнее было сделать наоборот - воспринимать
> все обращения по умолчанию, как HTTP запросы.
а они не могут. Там суть не в "по умолчанию" а в "нешмалга я распознать".
то есть единственное, что можно сделать, если уж задаться целью спасти доступ васяна к его ssh - это перечислять абсолютно все распознаваемые (regex або поштучно), а ssh по прежнему валить в default - его нечем матчить.
если бы авторы этого странного кода действительно имели ту же цель, что и васян, они бы добавили значение "unknown", отдельное от "default". Но у них явно была какая-то другая задача, а пример писал менеджер по рекламе, поэтому такая фигня и написана.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от Crazy Alex (ok), 31-Июл-18, 14:24 +/–

Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально стадартные полиси, не подходящие под половину реальных ситуаций. И подобными обходами пользуются тупо все - и для работы, и фоточки с котиками смотреть. И все об этом знают - ну просто потому, что это не криминал, а технически обойти проще, чем с бюрократией возиться. И быстрее - на месяцы. Соответственно, никакого DPI там нет в принципе, потому что тот, кто всё это настраивал, тоже понимал, скажем так, не универсальность требований.
Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было эффективно работать, не нарушая букву полиси.
Впрочем, обычно проще, конечно, тупо на 443 поднять ssl vpn.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17

16. Сообщение от Аноним (16), 31-Июл-18, 18:02 +/–

security by obscurity

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18

17. Сообщение от пох (?), 31-Июл-18, 22:21 +/–

> Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально
> стадартные полиси
и твоя стандартная подпись под ней. Ну и оно вот тебе - надо?
> И подобными обходами пользуются тупо все
потом начальству попадает возжа под хвост, админу надо на кого-то свалить проблему с вирусом, положившим пол-сети, меняется младший оператор зонда в отделе иб, или ты не так с кем-то здороваешься - и увольняют по статье, велев радоваться, что не заставили компенсировать "ущерб".
Ну и насчет "все" это явное преувеличение. Тетки в бухгалтерии тоже настраивают себе ssh на левых vps?
> Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было
> эффективно работать, не нарушая букву полиси.
я видел и работаю. интернет доступен в силу служебного положения, флэшки - нет. Ну и хер с ними.
Нужен конфиг vpn дома - ок, идем к начальству, оно допущено к актам владения переносными носителями. Нет на месте - значит, vpn из дома у меня пока не будет. За это еще никого не уволили.
не путать буквы с личными фанабериями админчиков - этим успешно можно прищемить хвост или игнорировать предоставляемый ими сервис. Но если подписал бумажку, что доступ в интернет строго для работы, потребные для работы сайты прилагаются списком - глупо наживать себе неприятности, да еще столь череззадничными методами.
а для дpoчева на опеннете есть мобило. Если и его заставляют сдавать при входе - нафига ж было там работать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #26, #36, #38

18. Сообщение от int13h (ok), 31-Июл-18, 23:54 +1 +/–

Коллега, неопытный администратор, которому кто-то выслал доступ к серверу в виде "root@blahblah -p443" начал править конфиги  nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку  рестартанул веб-сервер. Дальше, додумаете сами.
Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #19, #28

19. Сообщение от adsh (ok), 01-Авг-18, 00:39 +/–

> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить ключ - это уже почти то же самое, что заходить по паролю. Только пароль нужно держать в голове или в программе для хранения паролей со стойким паролем, опять же - в голове.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #20, #22

20. Сообщение от int13h (ok), 01-Авг-18, 00:49 +/–

>> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
> Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить
> ключ - это уже почти то же самое, что заходить по
> паролю. Только пароль нужно держать в голове или в программе для
> хранения паролей со стойким паролем, опять же - в голове.
Откройте порт -- в чем проблема?
Ну, если есть сложности с запоминанием пароля )
Просто на порт !=22 меньше "китайцев" будет стучать.
Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #21

21. Сообщение от adsh (ok), 01-Авг-18, 01:21 +/–

> Откройте порт -- в чем проблема?
Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя.
> Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно
Конечно неправильно и где-то даже отдаёт идиотизмом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #23

22. Сообщение от ssh (ok), 01-Авг-18, 09:37 +/–

> Паролить ключ - это уже почти то же самое, что заходить по паролю.
Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #24

23. Сообщение от int13h (ok), 01-Авг-18, 09:43 +/–

>Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя.
Мы говорим о хостинге или сервере (аппаратном, виртуализированном)? Если о хостинге, то Вам никто не даст стримить ssh через nginx

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #25

24. Сообщение от adsh (ok), 01-Авг-18, 15:12 +/–

> Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после
> каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;)
Вы сами себя обманули. Это от клиента зависит, как он работает с паролем к ключу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27, #29

25. Сообщение от adsh (ok), 01-Авг-18, 15:17 +/–

> Мы говорим о хостинге или сервере (аппаратном, виртуализированном)?
Вообще говоря - нужно спросить у автора, для какого случая это всё.
> Если о хостинге, то Вам никто не даст стримить ssh через nginx
Это может быть хостинг сервер с полным доступом, но пофайерволленный политикой компании и т.п.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

26. Сообщение от Crazy Alex (ok), 04-Авг-18, 11:50 +/–

Да никто не заставляет мобилы сдавать. Речь об обычных больших айтишных конторах, где "глобальная" полиси вечно конфликтует с нуждами и удобствами конкретных проектов, и в мелочах никто её не энфорсит, так как невозможно и половина разработчикв уволится на фиг из такого концлагеря (и найдёт себе другую работу за пару недель). Что там у тёток в бухгалтерии мне вообще не интересно, речь об айтишных решениях на айтишном ресурсе. А вот где точно не надо работать, так это там, где могут попытаться уволить, потому что "не так с кем-то здороваешься" и т.п. Благо, для программиста есть вагон более привлекательных вариантов, где даже в случае каких-то проблем сначала минимум пару раз вежливо пообщаются, и только потом, если не договоритесь, разорвут контракт.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

27. Сообщение от h31 (ok), 04-Авг-18, 12:37 +/–

От наличия и настроек ssh-agent, если уж так говорить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

28. Сообщение от Аноним (28), 05-Авг-18, 23:00 +/–

> nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку  рестартанул веб-сервер.
И nginx не рестартанул, а остался работать со старым конфигом, так как именно так он себя и ведет в приличных системах. Проверено электрониками.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #30

29. Сообщение от ssh (ok), 07-Авг-18, 14:48 +/–

> Вы сами себя обманули. Это от клиента зависит, как он работает с
> паролем к ключу.
Разумеется я имел ввиду клиент из комплекта OpenSSH, там именно так как я написал. Используйте агент и не сочиняйте нам тут. :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

30. Сообщение от Аноним (30), 22-Авг-18, 10:00 +/–

омг, restart != reload.
вы описали поведение для reload'а, а при restart'е выполняется остановка процесса и его запуск.
поэтому если конфиг битый запуск завершается с ошибкой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #31

31. Сообщение от moo (?), 04-Сен-18, 09:08 +/–

Зависит от ОС.
В нормальных - при restart'е перед стопом делается nginx -t.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #37

32. Сообщение от Google (?), 04-Сен-18, 17:56 +/–

https://github.com/google/huproxy

Ответить | Правка | Наверх | Cообщить модератору

33. Сообщение от atk91 (ok), 06-Сен-18, 13:36 +/–

почему нельзя просто на свой vds повесить sshd на 443 порт?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #39

34. Сообщение от Аноним (36), 12-Сен-18, 00:45 +/–

Ну ты же умнее автора примера, небось сообразишь как остальные версии прописать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

35. Сообщение от Аноним (36), 12-Сен-18, 00:47 +/–

> Так, а для чего это делать? Не, серьезно -- для чего?
А почему нет-то? Мало ли откуда приспичит до сервера достучаться, и может там все кроме 80/443 блокируют.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

36. Сообщение от Аноним (36), 12-Сен-18, 00:56 +1 +/–

А вы не думали что есть юзкейсы кроме того что ты раб который пyкнуть боится чтобы с работы по статье не пойти?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

37. Сообщение от nssnnssn (?), 20-Сен-18, 18:36 +/–

https://i.imgur.com/7hWAYId.png
да, все получилось

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

38. Сообщение от Максим (??), 20-Сен-18, 22:21 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #42

39. Сообщение от lv333 (ok), 22-Сен-18, 21:26 +/–

А вдруг там уже сайтик висит имени Васи Пупкина?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

40. Сообщение от Имя (?), 31-Окт-18, 11:12 +/–

Есть же sslh для этого.

Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Nolf (ok), 13-Мрт-19, 17:46 +/–

А как быть в ситуации если есть сервак с белым IP, а на нем 10 вируталок с сервми IP... И нужно ходить из вне на них по SSH?

Ответить | Правка | Наверх | Cообщить модератору

42. Сообщение от Full Master (?), 26-Мрт-21, 19:46 +/–

Туда всякие поцреоты идут.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Анонисмус (?), 25-Июл-18, 10:37	+1 +/–
Google: "SSH HTTPS multiplexing"
Ответить \| Правка \| Наверх \| Cообщить модератору

2. Сообщение от троллейбусизбуханки (?), 26-Июл-18, 10:01	+/–
но зачем? 8-O
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5

3. Сообщение от Василий (??), 26-Июл-18, 12:58	+/–
А есть ли возможность сделать подобное с витруальными-хостами ( server_name )? Например крутятся во многих lxc разные сайты и мы хотим давать доступ и по https и по ssh через единый nginx на хост системе
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #4, #7

4. Сообщение от Василий (??), 26-Июл-18, 13:04	+/–
Ага , вот тут наспиано как это сделать http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_modul... как я понял , можно написать еще один map по ssl_preread_server_name
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #8

5. Сообщение от Crazy Alex (ok), 28-Июл-18, 15:17	+/–
Например, чтобы пролезть оттуда, где вовне открыт доступ только на 80 и 443, на свой VDS
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #6, #33

6. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:50	–1 +/–
а тебе не ссыкотно? обычно где вовне он так открыт - еще при входе заставляют подписать бумажку, что на работе надо заниматься работой, а не по своим vds лазать. И учти, что pa/checkpoint/cisco умеют отличать ssl от левого протокола на тех же портах, тем же самым (и не только) способом. впрочем, гораздо чаще - на дороге стоит дешифрующий прокси, и никакой ssh через него не пролезет в принципе. а вот мобилы заставляют сдавать в камеру хранения гораздо позже.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #15

7. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:53	+/–
> А есть ли возможность сделать подобное с витруальными-хостами ( server_name )? нет. да и зачем? > Например крутятся во многих lxc разные сайты и мы хотим для этого есть sni, который прекрасно работает без этих ненужно-фокусов. > давать доступ и по https и по ssh через единый nginx а для ssh нет sni, да и не парсит его nginx, просто откидывая как "не-ssl" - поэтому попасть по ssh ты сможешь только на кого-то одного. Например на саму хост-систему, было бы чего ради огород-то городить...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

8. Сообщение от толлейбусизбуханки (?), 29-Июл-18, 18:54	+/–
> как я понял , можно написать еще один map по ssl_preread_server_name нельзя, нет в ssh никакого "server name".
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

9. Сообщение от adsh (ok), 30-Июл-18, 19:43	+/–
Это получается, что если долбиться в 443 порт как SSL (2,3), TLS (1.0,1.1) или любым другим, не TLS 1.2 образом, то всё это будет скормлено sshd? А ему не поплохеет? Молодцы...
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10, #13, #34

10. Сообщение от Аноним (10), 30-Июл-18, 21:00	–1 +/–
Если вашему sshd поплохеет из-за того, что ему от неаутентифицированного клиента прилетит в сокет мусор, то у вас какой-то неправильный sshd.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от adsh (ok), 30-Июл-18, 22:02	+1 +/–
Обычное количество HTTP запросов не идёт ни в какое сравнение с числом таковых же по SSH. Фактически, в статье описан рецепт, как сделать DOS на свой же сервер. Правильнее было сделать наоборот - воспринимать все обращения по умолчанию, как HTTP запросы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #14

12. Сообщение от int13h (ok), 30-Июл-18, 22:26	+2 +/–
Так, а для чего это делать? Не, серьезно -- для чего?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #16, #35

13. Сообщение от толлейбусизбуханки (?), 31-Июл-18, 12:04	+/–
да не переживайте так, васян-vds'у на котором этот конфиг бездумно скопипастили, чтобы "обойти систему", в общем-то пофиг. В том числе и тот факт, что пользователи неправильных браузеров сайта не увидят. а реальные применения препарсера - они для ids каких-нибудь имеют смысл, защит от атак ("ssl2 роняем на пол, это точно не человек, странные протоколы отправляем в один балансер, нормальные, реально используемые большинством юзеров - в другой"), еще чего в этом же роде - и там, уверяю, не ssh будет принимать default ;-)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

14. Сообщение от толлейбусизбуханки (?), 31-Июл-18, 12:09	+1 +/–
> Правильнее было сделать наоборот - воспринимать > все обращения по умолчанию, как HTTP запросы. а они не могут. Там суть не в "по умолчанию" а в "нешмалга я распознать". то есть единственное, что можно сделать, если уж задаться целью спасти доступ васяна к его ssh - это перечислять абсолютно все распознаваемые (regex або поштучно), а ssh по прежнему валить в default - его нечем матчить. если бы авторы этого странного кода действительно имели ту же цель, что и васян, они бы добавили значение "unknown", отдельное от "default". Но у них явно была какая-то другая задача, а пример писал менеджер по рекламе, поэтому такая фигня и написана.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

15. Сообщение от Crazy Alex (ok), 31-Июл-18, 14:24	+/–
Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально стадартные полиси, не подходящие под половину реальных ситуаций. И подобными обходами пользуются тупо все - и для работы, и фоточки с котиками смотреть. И все об этом знают - ну просто потому, что это не криминал, а технически обойти проще, чем с бюрократией возиться. И быстрее - на месяцы. Соответственно, никакого DPI там нет в принципе, потому что тот, кто всё это настраивал, тоже понимал, скажем так, не универсальность требований. Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было эффективно работать, не нарушая букву полиси. Впрочем, обычно проще, конечно, тупо на 443 поднять ssl vpn.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #17

16. Сообщение от Аноним (16), 31-Июл-18, 18:02	+/–
security by obscurity
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #18

17. Сообщение от пох (?), 31-Июл-18, 22:21	+/–
> Есть реальная безопасность, а есть заигравшиеся админы или, что гораздо чаще, банально > стадартные полиси и твоя стандартная подпись под ней. Ну и оно вот тебе - надо? > И подобными обходами пользуются тупо все потом начальству попадает возжа под хвост, админу надо на кого-то свалить проблему с вирусом, положившим пол-сети, меняется младший оператор зонда в отделе иб, или ты не так с кем-то здороваешься - и увольняют по статье, велев радоваться, что не заставили компенсировать "ущерб". Ну и насчет "все" это явное преувеличение. Тетки в бухгалтерии тоже настраивают себе ssh на левых vps? > Я вообще ещё не видел ни одного случая, чтобы в более-менее крупной конторе возможно было > эффективно работать, не нарушая букву полиси. я видел и работаю. интернет доступен в силу служебного положения, флэшки - нет. Ну и хер с ними. Нужен конфиг vpn дома - ок, идем к начальству, оно допущено к актам владения переносными носителями. Нет на месте - значит, vpn из дома у меня пока не будет. За это еще никого не уволили. не путать буквы с личными фанабериями админчиков - этим успешно можно прищемить хвост или игнорировать предоставляемый ими сервис. Но если подписал бумажку, что доступ в интернет строго для работы, потребные для работы сайты прилагаются списком - глупо наживать себе неприятности, да еще столь череззадничными методами. а для дpoчева на опеннете есть мобило. Если и его заставляют сдавать при входе - нафига ж было там работать?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #26, #36, #38

18. Сообщение от int13h (ok), 31-Июл-18, 23:54	+1 +/–
Коллега, неопытный администратор, которому кто-то выслал доступ к серверу в виде "root@blahblah -p443" начал править конфиги nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку рестартанул веб-сервер. Дальше, додумаете сами. Не проще ли использовать порт, к примеру, 22732 + доступ по ключу?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #19, #28

19. Сообщение от adsh (ok), 01-Авг-18, 00:39	+/–
> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу? Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить ключ - это уже почти то же самое, что заходить по паролю. Только пароль нужно держать в голове или в программе для хранения паролей со стойким паролем, опять же - в голове.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #20, #22

20. Сообщение от int13h (ok), 01-Авг-18, 00:49	+/–
>> Не проще ли использовать порт, к примеру, 22732 + доступ по ключу? > Порт может быть закрыт, а ключ можно украсть вместе с компом. Паролить > ключ - это уже почти то же самое, что заходить по > паролю. Только пароль нужно держать в голове или в программе для > хранения паролей со стойким паролем, опять же - в голове. Откройте порт -- в чем проблема? Ну, если есть сложности с запоминанием пароля ) Просто на порт !=22 меньше "китайцев" будет стучать. Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19 Ответы: #21

21. Сообщение от adsh (ok), 01-Авг-18, 01:21	+/–
> Откройте порт -- в чем проблема? Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя. > Я про то, что смысла стримить трафик ssh через nginx нет, это как-то неправильно Конечно неправильно и где-то даже отдаёт идиотизмом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #20 Ответы: #23

22. Сообщение от ssh (ok), 01-Авг-18, 09:37	+/–
> Паролить ключ - это уже почти то же самое, что заходить по паролю. Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19 Ответы: #24

23. Сообщение от int13h (ok), 01-Авг-18, 09:43	+/–
>Описанный в статье рецепт относится к ситуации, когда на хостинге открыты только заданные порты и изменить это нельзя. Мы говорим о хостинге или сервере (аппаратном, виртуализированном)? Если о хостинге, то Вам никто не даст стримить ssh через nginx
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #25

24. Сообщение от adsh (ok), 01-Авг-18, 15:12	+/–
> Вас обманули. Пасс-фраза вводится один раз при авторизации в системе, опционально после > каждой разблокировки экрана. А к хостам подключаетесь посредством ssh host ;) Вы сами себя обманули. Это от клиента зависит, как он работает с паролем к ключу.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22 Ответы: #27, #29

25. Сообщение от adsh (ok), 01-Авг-18, 15:17	+/–
> Мы говорим о хостинге или сервере (аппаратном, виртуализированном)? Вообще говоря - нужно спросить у автора, для какого случая это всё. > Если о хостинге, то Вам никто не даст стримить ssh через nginx Это может быть хостинг сервер с полным доступом, но пофайерволленный политикой компании и т.п.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23

26. Сообщение от Crazy Alex (ok), 04-Авг-18, 11:50	+/–
Да никто не заставляет мобилы сдавать. Речь об обычных больших айтишных конторах, где "глобальная" полиси вечно конфликтует с нуждами и удобствами конкретных проектов, и в мелочах никто её не энфорсит, так как невозможно и половина разработчикв уволится на фиг из такого концлагеря (и найдёт себе другую работу за пару недель). Что там у тёток в бухгалтерии мне вообще не интересно, речь об айтишных решениях на айтишном ресурсе. А вот где точно не надо работать, так это там, где могут попытаться уволить, потому что "не так с кем-то здороваешься" и т.п. Благо, для программиста есть вагон более привлекательных вариантов, где даже в случае каких-то проблем сначала минимум пару раз вежливо пообщаются, и только потом, если не договоритесь, разорвут контракт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

27. Сообщение от h31 (ok), 04-Авг-18, 12:37	+/–
От наличия и настроек ssh-agent, если уж так говорить.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24

28. Сообщение от Аноним (28), 05-Авг-18, 23:00	+/–
> nginx и ошибся, не выполнив nginx -t, совершив синтаксическую ошибку рестартанул веб-сервер. И nginx не рестартанул, а остался работать со старым конфигом, так как именно так он себя и ведет в приличных системах. Проверено электрониками.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #30

29. Сообщение от ssh (ok), 07-Авг-18, 14:48	+/–
> Вы сами себя обманули. Это от клиента зависит, как он работает с > паролем к ключу. Разумеется я имел ввиду клиент из комплекта OpenSSH, там именно так как я написал. Используйте агент и не сочиняйте нам тут. :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24

30. Сообщение от Аноним (30), 22-Авг-18, 10:00	+/–
омг, restart != reload. вы описали поведение для reload'а, а при restart'е выполняется остановка процесса и его запуск. поэтому если конфиг битый запуск завершается с ошибкой.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #28 Ответы: #31