Comments 94
А в чем смысл использования ssh в этой задаче? ИМХО, намного проще воспользоваться скриптом настройки vpn и работать через него. Это упростит настройку клиентов(скачать openvpn, установить, подкинуть в нужный каталог ключ и прописать в автозапуск) и уменьшит возможные последствия для арендатора сервера — ssh кроме проброса порта позволяет создать socks прокси и кто-то этим может воспользоваться для «обхода блокировок».
В случае использования vpn можно настроить правила маршрутизации трафика между машинами. Например, пользователь А может сходить на свою домашнюю машину и на локальный сервер CS 1.6, а пользователь Б только на домашнюю машину.
В случае использования vpn можно настроить правила маршрутизации трафика между машинами. Например, пользователь А может сходить на свою домашнюю машину и на локальный сервер CS 1.6, а пользователь Б только на домашнюю машину.
Принципиально такая поделка на SSH эквивалента VPN, разница лишь в том, что адресация по паре «IP адрес: порт» фактически заменена на адресацию просто по номеру порта (ну и действительно процедура настройки автозапуска клиентов сложнее чем в случае OpenVPN). Есть незначительная удобная мелочь в том что для подключения к дому с какого-то третьего компьютера SSH можно запустить не имея админских прав (в отличие от OpenVPN). Ну и сервер настраивать однозначно проще (нужно ровно ничего не делать сверх запуска ВМ в облаке).
Про socks-прокси и политики — согласен. В следующей статье как раз планировал попиарить опенсорсную поделку, которая позволяет и всё кроме порт форвардинга запретить и политики доступа написать.
Про socks-прокси и политики — согласен. В следующей статье как раз планировал попиарить опенсорсную поделку, которая позволяет и всё кроме порт форвардинга запретить и политики доступа написать.
С разницей в настройке сервера с помощью опенсорсного скрипта можно поспорить — скрипт сам устанавливает(лучше конечно посмотреть что он поставит или попросить кого-то) все что нужно для работы openvpn, а после этого работает мастер, с помощью которого можно как добавить пользователя, так и удалить, что проще чем искать нужный ключ в authorized_keys.
Закрыть трафик во внешку можно одним исправлением конфига openvpn. Настроить маршруты сложнее, но в большинстве случаев это и не нужно.
Запуск с третьего компьютера без прав… а надо ли? Если кто-то запретил создавать подключения, то зачем нарываться на неприятности? А если не запрещал и это просто компьютер у друга, то можно попросить запустить клиента с нужными правами.
ЗЫ. А вот про поделку для настройки доступа было бы интересно почитать.
ЗЫЗЫ. ЕМНИП, когда OpenShift был бесплатным, то в нем скорость ssh проброса сильно резалась. Админить систему можно было, а вот закинуть большой файл уже сложнее.
Закрыть трафик во внешку можно одним исправлением конфига openvpn. Настроить маршруты сложнее, но в большинстве случаев это и не нужно.
Запуск с третьего компьютера без прав… а надо ли? Если кто-то запретил создавать подключения, то зачем нарываться на неприятности? А если не запрещал и это просто компьютер у друга, то можно попросить запустить клиента с нужными правами.
ЗЫ. А вот про поделку для настройки доступа было бы интересно почитать.
ЗЫЗЫ. ЕМНИП, когда OpenShift был бесплатным, то в нем скорость ssh проброса сильно резалась. Админить систему можно было, а вот закинуть большой файл уже сложнее.
Проблема с OpenVPN в том, что «из коробки» это решение для выдачи доступа во всю сеть, а не к отдельным сервисам в этой сети. Можно, конечно, нагородить кучу правил в таблице маршрутизации (или даже iptables на стороне сервера VPN), но чувствуется несоответствие инструментария (управление сетью на Layer 4) предметной области задачи (Layer 7) в случае, когда нужно раздать доступ именно к сервисам (sql, web, etc), а не обеспечить прохождение произвольных пакетов из одной подсети в другую.
Например, такой сценарий: компания хочет дать временной доступ (другой компании или контрактору) к базу данных или ко внутреннему веб-приложению. Это можно сделать одной командой SSH, запущенной из корпоративной сети, для соединения с неким внешним SSH сервером (управляемым контрактором). Никакого дополнительного софта, доступ по самому минимуму (фиксированный IP:port) и никаких лишних дыр в безопасноти. С OpenVPN пришлось бы изрядно поколхозить для достижения такого же результата…
Например, такой сценарий: компания хочет дать временной доступ (другой компании или контрактору) к базу данных или ко внутреннему веб-приложению. Это можно сделать одной командой SSH, запущенной из корпоративной сети, для соединения с неким внешним SSH сервером (управляемым контрактором). Никакого дополнительного софта, доступ по самому минимуму (фиксированный IP:port) и никаких лишних дыр в безопасноти. С OpenVPN пришлось бы изрядно поколхозить для достижения такого же результата…
Да, для такого сценария SSH удобнее, полностью согласен, но для решения задачи из поста или если нужно разрешить десяток портов, а к остальным запретить доступ — увольте =)
Думаю, настроить iptables и openvpn через web-морду или консоль будет быстрее создания нового пользователя и прописывания нужных разрешений для проброса в конфиге.
Думаю, настроить iptables и openvpn через web-морду или консоль будет быстрее создания нового пользователя и прописывания нужных разрешений для проброса в конфиге.
С точки зрения безопасности — то, что Вы предлагаете фигня, т.к. обычно требуется поддержка со стороны приложения. Например, нужен доступ в БД. А эта БД — какой-то большой Oracle или Postgres, где все данные компании. Получается, нужно еще создавать вьюху и создавать отдельного пользователя именно на уровне самой БД.
REST сервисы можно загнать за nginx и на уровне него разрулить какой юзер должен иметь доступ куда.
Это не отменяет ограничений по IP и портам, но, как говорится, безопасность — это комплекс мер.
Вопрос в том, что все эти меры должны быть доступны из какой-то единой панели…
REST сервисы можно загнать за nginx и на уровне него разрулить какой юзер должен иметь доступ куда.
Это не отменяет ограничений по IP и портам, но, как говорится, безопасность — это комплекс мер.
Вопрос в том, что все эти меры должны быть доступны из какой-то единой панели…
Ситуацию можно улучшить отказавшись от велосипеда с подвывертами и поставив OpenVPN или аналог.
Задачу точно можно решить по другому поставив OpenVPN или аналог. Даже в случае с OpenVPN у нас присутствует необходимость хостить машину-«маршрутизатор» (по совместительству OpenVPN-сервер) где-то в интернете, либо сделать такой машиной домашний компьютер, но тогда нужно обеспечить ему постоянный глобальный адрес. Короче говоря ровно все те же самые соображения.
Смысл статьи в том, чтобыизобрести велосипед показать что простые сценарии можно реализовывать и без VPN с помощью средств, которые из коробки есть в большинстве современных ОС.
Смысл статьи в том, чтобы
У OpenVPN или аналогов есть один недостаток: их трафик отлично вычисляется DPI-системами провайдеров и легко запихивается шейпером в тонюсенькую трубочку. То есть вроде и работает, но скорость ниже плинтуса. Попадаются провайдеры, которые это практикуют. А некоторые провайдеры так вообще не напрягаются с DPI, а просто запихивают весь клиентский UDP-трафик в такую трубку. SSH же пока что никто не шейперит. Не считают нужным.
К слову, OpenVPN неплохо работает и по TCP-IP. А у каких провайдеров vpn режется? Хотелось бы знать что бы не нарваться.
Нормальный DPI узнает чистый OpenVPN даже, если он работает по TCP (и в том числе косит под HTTPS на 443 порту). Там своеобразный handshake используется. WireShark'а под рукой нет, но вот довольно старая статья на Хакере, где показана разница.
Старая статья на Хакере — это хорошо, но есть гораздо более простой документ — код детектора из nDPI.
Нормальный DPI узнает, а если просто режется UDP, то может и прокатить.
За статью спасибо, посмотрю на досуге.
За статью спасибо, посмотрю на досуге.
Например в Китае. В командировках по openvpn попасть на машину в России не представляется возможным. А по ssh — работает.
Прямо сейчас я выхожу в интернет именно через такого провайдера. А через какого конкретно — не скажу, уж извините, потому как не готов делиться информацией о своём местонахождении со всем интернетом. Просто имейте в виду, что на данный момент практически любой провайдер имеет техническую возможность ограничить/заблокировать широко известные протоколы VPN. Есть, правда, протокол SSTP — хорошо маскирующийся под HTTPS — не знаю как сейчас у провайдеров дела обстоят с ним.
Китайцы в эти «никто» не входят. SSH cначала режут, потом банят порт, потом целиком ip (China Mobile домашняя оптика). OpenVPN получает бан практически мгновенно.
OpenVPN или аналог
Насколько я знаю, практически любой vpn-клиент захочет админских прав, как при установке (для сетевого драйвера), так и при подключении (для правки роутинга). Админские права на ssh-клиенте есть далеко не всегда.
ssh же умеет делать как бы свой «vpn» :) habr.com/ru/post/87197
к вам на супер-секретный порт 32167Эй! Откуда ты узнал-то? Немедленно удали! >:E
Пользуясь случаем, спрошу. Есть ли какой нибудь дружелюбный инструмент управления ssh сервером, скажем через web для домохозяек:) без регистрации и смс?
Можно использовать и классический клиент для ssh putty:
blog.afach.de/?p=606
Запуская данный cmd так:
blog.afach.de/?p=606
Запуская данный cmd так:
set path=C:\Program Files\PuTTY;C:\Python37\;
c:
cd "C:\Program Files\PuTTY"
python ssh-reconnect.pyэто не то что нужно, а реконекты хорошо подкрутили в kitty
еще есть Bitvise SSH Client, там есть и реконнекты, и настройка в gui и портфорварда и сокс и вот это все.
www.bitvise.com/ssh-client
www.bitvise.com/ssh-client
Заодно поставить себе/друга/знакомого на комп и putty и интерпретатор python. Просто чтобы зайти по RDP.
Такое работает, только если в протоколе L7 не фигурируют хостнеймы. Ну, например, у Вас веб-сервер на защищаемом сервере, с настроенными virtual hosts. Как тогда будете выкручиваться?
Думаю, что нужные хостнеймы он пропишет в hosts на 127.0.0.1, если это винда. А если убунту с локальным dnsmasq то это уже совершенно другая история =)
Легко. В /etc/hosts (c:\Windows\System32\drivers\etc\hosts) добавить 127.0.0.1 my.any.host
В браузере my.any.host Если сертификат валидный, и с ним нет проблем. Всегда так делаю
В браузере my.any.host Если сертификат валидный, и с ним нет проблем. Всегда так делаю
Угу, прекрасное решение. Для начала нужно обладать админскими правами, чтобы это сделать. Вторая история, что это работает «насовсем». Либо нужно костылить скрипты, которые будут эти доменные имена прописывать в нужный момент времени. И третий момент, что если на той стороне веб-приложение, которое редиректит (и должно знать свой адрес), то редирект может сломаться (например, перешли my.any.host:444, т.к. порт 443 висит на другом сервисе, а приложуха думает, что она на my.any.host и строит редирект в my.any.host/my_page.html).
Я к тому, что ситуации бывают разные… и нужны разные подходы. Но то, что описали — имеет право на существование.
И еще раз доказывает, что NAT и IPv4 адреса ни от чего не защищают толком…
Я к тому, что ситуации бывают разные… и нужны разные подходы. Но то, что описали — имеет право на существование.
И еще раз доказывает, что NAT и IPv4 адреса ни от чего не защищают толком…
Меня видимо одного посетил вопрос «это все нужно сделать, чтобы не брать у провайдера внешний ip?» Даже у ОпСоСов реально выпросить статичные внешние ip (от имени ИП, разумеется).
Описанная в статье игра тем более не стоит свеч. Это неудобно (привет wifi с реконнектами), это медленнее (латенси никуда не пропадает).
«рано или поздно к вам на супер-секретный порт 32167 прилетит TCP SYN родом из китайской деревушки» миллионы серверов работают с открытым стандартным портом rdp. да, брутят. брутят в основном учетную запись «Администратор», которая по умолчанию отключена. ЗаDos'ят? бросьте, кому нужны.
Описанная в статье игра тем более не стоит свеч. Это неудобно (привет wifi с реконнектами), это медленнее (латенси никуда не пропадает).
«рано или поздно к вам на супер-секретный порт 32167 прилетит TCP SYN родом из китайской деревушки» миллионы серверов работают с открытым стандартным портом rdp. да, брутят. брутят в основном учетную запись «Администратор», которая по умолчанию отключена. ЗаDos'ят? бросьте, кому нужны.
То есть ИП зарегистрировать (который больше ни для чего не нужен) — проще и дешевле?
Ок, в дорогом продакшене лучше уже платить деньги.
Пример встречной ситуации — небольшая компания снимает офис в небольшом бизнес-центре, где благодаря монополизму местный "провайдер" вообще не чешется на предоставление каких-либо услуг кроме "исходящий интернет для сотрудников".
Как, даже при очень большом желании админу маленькой компании пробуриться через NAT/PAT снаружи до своего любимого сервера?
Тимвьювер? Впн наружу?
Если смотреть за пределы облака яндекса, то цены будут радовать заметно сильнее. Но в любом случае это не отменяет потребности настраивать инфраструктуру на внешнем сервере.
Так почему бы при наличии уже действующего внешнего сервера (тот же хостинг) не использовать побочный бонус?
Виндоюзерам дали ссш, и они начали делать костыли возрастом лет 10-15)
Скажите, а почему яндекс облако? Ведь обычная вдс будет стоить намного дешевле, например один из популярных российских вдс хостингов предлагает конфигурацию с 1 ядром и гигабайтом оперативы за 160 рублей в месяц.
Ну и да, на этом же вдс вполне можно поднять впн сервер и иметь гораздо больше возможностей
Ну и да, на этом же вдс вполне можно поднять впн сервер и иметь гораздо больше возможностей
Я в google cloud видел какую-то совсем стоковую машинку (типа 0.5гб и 1-2 ядер), которую можно бесплатно использовать 31 день в месяц — типа одну такую машинку можно держать всегда включенной. (да и если небесплатно использовать — цена явно гуманннее, чем у яндекса.)
P.s. Более интересным выглядит вариант не использовать внешний сервер, ну или использовать его только как точку рандеву, чтобы пробиться сквозь nat.
Да-да. За 200 в месяц можно взять vscale. Или просто белый IP домой у своего провайдера.
А если рассматривать Европу, то и за 1 EUR /mo можно получить VPS с белым ipv4
А если рассматривать Европу, то и за 1 EUR /mo можно получить VPS с белым ipv4
И правда. Действительно, так существенно дешевле. Каких-то особенных причин использовать именно облако а не ВДС нет. Век живи — век учись.
Знаю я одного такого. Но у него по правилам запрещено ставить прокси, VPN и прочее. Так что могут и забанить в самый неподходящий момент. А вот в Европе можно и за пол яндексовской цены взять для таких целей, но пинг будет, понятное дело почему, хуже.
Комментарий не по сути статьи, а мелкое замечание:
В shell вместо $HOME можно использовать ~.
Намного короче и удобнее печатать: cat ~/.ssh/id_rsa.pub вместо громоздкого трудно печатаемого из-за необходимости удерживать Shift cat $HOME/.ssh/id_rsa.pub.
Ещё в расход надо бы добавить Windows Professional на домашней машине: предустановлена таки чаще Home, у которой возможность подключения к ней по rdp отключена.
github.com/stascorp/rdpwrap Реально работает.
The goal of this project is to enable Remote Desktop Host support and concurrent RDP sessions on reduced functionality systems for home usage.
RDP Wrapper works as a layer between Service Control Manager and Terminal Services, so the original termsrv.dll file remains untouched. Also this method is very strong against Windows Update.
The goal of this project is to enable Remote Desktop Host support and concurrent RDP sessions on reduced functionality systems for home usage.
RDP Wrapper works as a layer between Service Control Manager and Terminal Services, so the original termsrv.dll file remains untouched. Also this method is very strong against Windows Update.
В общем, для многих вариант поставить TV на машину будет более работающим и логичным. Тем более если тебе нужно, именно что, зайти на машину, включить Бетховена, и проведать свою майнинг-ферму. Собственно, даже TV стоит недорого, не говоря, что есть (для личного пользования) и некоторое кол-во других решений.
Я не ратую за замену ssh на tv, я про прямое решение задачи. Хочешь поуправлять компом — настрой управление компом, а не страдай с VPS-кой!
Я не ратую за замену ssh на tv, я про прямое решение задачи. Хочешь поуправлять компом — настрой управление компом, а не страдай с VPS-кой!
Teamviewer гонит весь трафик через свои сервера. Я бы не стал его использовать для доступа к своему компьютеру на постоянной основе именно в плане безопасности. Опять же насчёт статьи: насколько я понял, она про ssh и про то, что его можно использовать не только по прямому назначению. А доступ с компа на комп через VPS приведён в качестве примера такого использования.
«даже TV стоит недорого» — 2000 в месяц?
Ну и в целом пока что купить белый IP — это 200р. в месяц, что позволяет и без извратов с VPS делать. А для извратов можно и за 1 EUR взять сервер с белым IP в Европе.
Ну и в целом пока что купить белый IP — это 200р. в месяц, что позволяет и без извратов с VPS делать. А для извратов можно и за 1 EUR взять сервер с белым IP в Европе.
дешевле VPS за 55р/месяц, а через него уже что угодно настраивай, ssh+vnc например
А вы на что отвечали: на фразу «Я не ратую за замену ssh на tv, я про прямое решение задачи»?
P.S. И, конечно, vnc — никак не замена tv. Ну вот как ни крутите. Я про набор фич и качество картинки… Но, конечно, по соотношению «цена/качество» tv проиграет любому бесплатному продукту, тут тоже не о чем спорить.
P.S. И, конечно, vnc — никак не замена tv. Ну вот как ни крутите. Я про набор фич и качество картинки… Но, конечно, по соотношению «цена/качество» tv проиграет любому бесплатному продукту, тут тоже не о чем спорить.
В обратном режиме слушающий TCP-порт открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента. Пригождается такое редко, но, как правило, очень метко.
На самом деле, пригождается такое очень часто, когда вам нужно сделать себе нормальный RDP-доступ к машине, которая расположена в какой-нибудь корпоративной сети с драконовскими политиками удаленного подключения.
На машине запускается ssh-клиент (+ cntlm, если корпоративная прокся не разрешает basic) и на ssh-сервер публикуется localhost:3389 от машины (не забудьте только разрешить в настройках ssh-сервера ssh-клиентам указывать на каком интерфейсе публиковать, иначе порт опубликуется на всех). Кстати, putty и kitty для этого сценария не подходят — у них есть странный глюк, что rdp-подключение пройдет, но тут же отвалится. А вот bitvise ssh client исполняет такое без проблем.
github.com/maxlinus/BrynhildrHelpdesk, использую 3 связки: br+kitty, vnc+kitty, rdp+kitty, глюков не наблюдал
Ну вы конечно и придумали. А я просто настроил DDNS бесплатный и перебросил порт на комп.
Всё классно, единственный нюанс — открытость этого порта не только для вас, но и для любого пользователя из интернета. При наличии уязвимости в сервере RDP — ваш компьютер уже не совсем ваш.
В предложеной экзотической схеме для получения доступа к вашему компьютеру требуется уже две уязвимости — одна в сервере SSH, другая в сервере RDP.
Ну и не всегда сейчас провайдер даёт конечному оборудованию глобальный IP-адрес, пусть и динамический.
В предложеной экзотической схеме для получения доступа к вашему компьютеру требуется уже две уязвимости — одна в сервере SSH, другая в сервере RDP.
Ну и не всегда сейчас провайдер даёт конечному оборудованию глобальный IP-адрес, пусть и динамический.
а всегда ли DDNS пробивается через провайдерский nat?
Я конечно могу сильно ошибаться, но в данном варианте использования не проще было «завести» Hamachi на дескотопе и просто добавить необходимые устройства в сеть. Да, в бесплатной версии там есть ограничения, но много кому в данном сценарии использования необходимо больше машин? По поводу запуска стороннего приложения на каждой из машин участников сети, не расцениваю это как большой минус.
А если «на каждой из заранее неизвестного множества машин» (упомянутый выше в комментах случай «зайти от друга»)?
Как минимум для «зайти от друга» вам необходимо будет иметь в наличии ваш RSA ключ и иметь " в голове" адресс связующего сервера. Что мешает иметь на флешке клиент hamachi?
Да и сорить секретными ключами на «неизвестном множестве» не хочется. а если начинать автоматизировать дело по их контролю, то тут мне кажется мы выходим за рамки «простого способа»
Да и сорить секретными ключами на «неизвестном множестве» не хочется. а если начинать автоматизировать дело по их контролю, то тут мне кажется мы выходим за рамки «простого способа»
Я для решения этой задачи использую ZeroTier. Не нужны внешние сервера, все устройства получаются в одной локалке, где бы они не находились.
Какая ненавязчивая реклама я.
Извините чайника, но бесплатные лимиты AWS тоже позволят развернуть такую инфраструктуру?
Сначала порадовался тому, что и яндекс стал давать облачные сервера в аренду, а потом посмотрел на цену и понял, почему я об этом до сих пор не знал. Облачный сервер с такими параметрами реально купить в 8-10 раз дешевле в очень многих местах. Смысл предложения яндекса не очень понятен, цена похожа на заградительную.
Потому что нужно сравнивать услуги одного класса. Условно — какой-нибудь хостинг типа Hetzner/timeweb/flops вообще не про то же самое, что и Яндекс. Одно — тупые VDS на непонятном оборудовании, второе — виртуальная инфраструктура с широким спектром доп. услуг. Понятно, что они могут быть не нужны, поэтому первые и выживают.
Попробовал описанное в статье. Как-то очень ненадежно получается.
дома raspberry, на котором включены sshd и сервер vnc, а в файле /etc/rc.local прописано:
Сразу после старта малинки через такой «VPN» доступен или порт 22001 (ssh), или 5900 (VNC). А через какое-то время все отваливается вообще. Хотя на малине в процессах виден ssh-клиент, подключенный куда надо.
Пробовал подключаться к серверу хостера, а также к собственному серверу, где уж точно нет никаких ограничений со стороны sshd. ЧЯДНТ?
дома raspberry, на котором включены sshd и сервер vnc, а в файле /etc/rc.local прописано:
sleep 20; autossh -N -R 22001:localhost:22 -R 5900:localhost:5900 -i <ключик> user@some.host.com & >/dev/null 2>&1
Сразу после старта малинки через такой «VPN» доступен или порт 22001 (ssh), или 5900 (VNC). А через какое-то время все отваливается вообще. Хотя на малине в процессах виден ssh-клиент, подключенный куда надо.
Пробовал подключаться к серверу хостера, а также к собственному серверу, где уж точно нет никаких ограничений со стороны sshd. ЧЯДНТ?
Может быть какой-то из роутеров по пути от вас до SSH-сервера имеет короткий срок жизни TCP-сессий в своей таблице NAT. По умолчанию SSH-сервер настроен так, чтобы не посылать никаких лишних пакетов. Иными словами, если клиент подключился, и ничего не делает, а серверу нечего ему сказать, то никаких данных по TCP-подключению не передаётся. Домашний роутер запросто может быть настроен так, чтобы забывать TCP-подключения после, к примеру, 10 минут простоя. Может получиться так, что TCP-сессия reverse port forwarding-стороны уже давным давно забыта на роутере, но SSH-клиент и SSH-сервер по-прежнему считают что между ними установлено TCP-подключение.
Это можно решить установкой параметров ServerAliveInterval на SSH-сервере и ClientAliveInterval на SSH-клиенте. Если установить их оба в, к примеру, 300, то каждые 5 минут будет происходить обмен Keep-Alive сообщениями, что, в свою очередь, будет убеждать все промежуточные роутеры в том, что сессия жива. Кроме того, даже если какой-то из этих роутеров по какой-то причине сбросит сессию, клиент и сервер будут способны относительно быстро этот факт обнаружить и установить подключение повторно.
Это можно решить установкой параметров ServerAliveInterval на SSH-сервере и ClientAliveInterval на SSH-клиенте. Если установить их оба в, к примеру, 300, то каждые 5 минут будет происходить обмен Keep-Alive сообщениями, что, в свою очередь, будет убеждать все промежуточные роутеры в том, что сессия жива. Кроме того, даже если какой-то из этих роутеров по какой-то причине сбросит сессию, клиент и сервер будут способны относительно быстро этот факт обнаружить и установить подключение повторно.
Sign up to leave a comment.
VPN без VPN или рассказ об нетрадиционном использовании SSH