Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизован IETF в 2006 году. С тех пор он успел стать де-факто стандартом для удалённого управления системами с текстовой консолью. Помимо собственно текстовой консоли в протоколе предусмотрена масса других полезных функций, таких как передача файлов и переадресация портов. Именно о переадресации портов (port forwarding) и её не слишком очевидном применении пойдёт речь в этой статье.
В протоколе SSH предусмотрено два режима переадресации портов — прямой и обратный. Прямой режим позволяет открыть слушающий TCP-порт на стороне SSH-клиента и переадресовать все подключения к этому порту на сторону сервера.
К примеру, если на нашем SSH-сервере выполняется сервер удалённого рабочего стола (Remote Desktop, RDS), мы можем использовать протокол SSH, чтобы подключиться к этому серверу, даже если прямое сетевое подключение невозможно (к примеру, заблокировано межсетевым экраном). Вот так:
Второй режим переадресации портов — обратный — позволяет поменять местами роли SSH-сервера и клиента (применительно к переадресуемому порту). В обратном режиме слушающий TCP-порт открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента. Пригождается такое редко, но, как правило, очень метко.
Комбинируя эти два режима и наш пример с сервером удалённого рабочего стола можно получить вот такую конфигурацию:
На первый взгляд, выглядит избыточно. Но вместе с кажущейся избыточностью мы получили два важных свойства:
- Единственное, что требуется от сети, чтобы такая схема работала корректно, — обеспечить постоянство сетевого адреса узла, где размещён SSH-сервер. Узлы, на которых выполняются сервер и клиент RDS, могут менять свои сетевые адреса хоть каждую минуту (либо вообще могут иметь адреса в частной сети, нам требуется лишь исходящий NAT, что часто и подразумевается под формулировкой «подключение к интернету»).
- Несмотря на то, что для нас самих RDS-сервер доступен из любой точки интернета, другие пользователи не могут установить к нему подключение (при условии отсутствия уязвимостей в SSH-сервере). А поскольку в протоколе RDS имеется собственный контроль доступа, даже в случае успешной атаки на SSH-сервер, злоумышленнику нужно будет провести еще и атаку на RDS. Вероятность наличия одновременно уязвимости SSH-сервере и уязвимости RDS-сервера, много меньше такой вероятности для каждого компонента в отдельности.
Если приглядеться внимательнее, то на этой схеме можно разглядеть две независимые компьютерные сети. Одна — транспортная — позволяет установить SSH-подключения. Другая — внутренняя — используется для прикладных целей. Из этого наблюдения в последующих статьях мы попробуем сделать несколько интересных выводов, ну а пока вернёмся к нашим экспериментам.
Подключись к домашнему компьютеру
На дворе XXI век, доставка сетевого пакета из Сибири в Калифорнию занимает 0.1 секунды, весь мир опутан компьютерными сетями, а TCP/IP есть даже в зубных щетках. Казалось бы, при такой-то связности всего со всем, мы должны давным давно иметь возможность управлять компьютером не только посредством физического присутствия возле устройств ввода, но и удалённо, по сети. Тем более что технологий и протоколов для этого — предостаточно. Remote Desktop от Microsoft, вариации на тему VNC в *nix системах, решения от Citrix, тысячи их… Тем не менее мало кто из нас может похвастаться возможностью подключиться к своему домашнему компьютеру из любой точки мира при помощи какой-нибудь из этих технологий.
Причин, по которым мало кто может похвастаться связью со своим собственным домашним компьютером, две, и они связаны друг с другом. Первая из них — отсутствие у типичного домашнего компьютера адреса в глобальной сети. Корни такого положения дел уходят в далёкий 1981 год, в котором был впервые описан стандарт IPv4, который и по сей день используется (само собой, с изменениями и дополнениями) для адресации большинства узлов в сети Интернет. Авторы стандарта решили, что адресного пространства мощностью в 3.7 миллиарда адресов хватит всем устройствам мира, но реальность оказалась сурова. Ожидается, что в IPv4-интернете не останется свободных адресов к сентябрю 2019 года.
Кроме того, типичный пользователь интернета, который не хостит у себя веб-сайты, вполне может пользоваться всеми благами цивилизации не имея адреса в глобальной сети, вместо этого ограничиваясь лишь адресом в частной сети и провайдерским NAT'ом. Иными словами, для большинства пользователей интернета нет разницы между наличием и отсутствием глобального IP-адреса у их оборудования. В таких условиях число тех, кому провайдер выдаёт глобальный IP-адрес в глобальной сети, стремительно сокращается. В итоге типичный домашний компьютер располагается в частной сети, и глобального адреса не имеет. Даже в случае, когда провайдер всё же назначает оборудованию пользователя адрес в глобальной сети, этим оборудованием является домашний роутер, выполняющий NAT из домашней частной сети. Пользователь при этом, конечно, может «пробросить порт» на роутере, но даже в этом лучшем случае глобальный адрес роутера может меняться изо дня в день. Да, существуют провайдеры, которые за скромную плату предоставляют услугу «Статический IP», но на практике где-то к этому моменту пользователь осознаёт, что игра не стоит свеч, и если нужно что-то сделать с домашним компьютером, то можно и по телефону позвонить.
Самые же настырные могут пройти этот квест до конца и столкнуться со второй причиной, по которой открывать доступ к своему компьютеру через интернет — развлечение лишь для крепких духом. Эта причина банальна — информационная безопасность. Глобальная сеть на то и глобальная, что рано или поздно в ваши ворота постучится кто-нибудь с другого конца света и с недобрыми намерениями. Насканить открытый порт, на котором отвечает сервер удалённого рабочего стола, — не слишком сложная задача, и, будьте уверены, рано или поздно к вам на супер-секретный порт 32167 прилетит TCP SYN родом из китайской деревушки.
Возвращаясь назад к нашей экзотической переадресации портов при помощи SSH, можно заметить, что её особенности устраняют обе перечисленные причины.
Собери себе TeamViewer
Сразу нужно оговориться, что TeamViewer — это большой продукт с огромным количеством очень разных возможностей. Мы же в рамках этой статьи соберём себе лишь способ безопасно подключаться через сеть Интернет по протоколу Remote Desktop к компьютеру, который находится за NAT. Тем не менее, рискну предположить, что именно подключение к любому компьютеру, имеющему доступ в интернет, — главная отличительная черта TeamViewer, благодаря которой этот продукт так популярен. И именно такое подключение мы можем реализовать собственными руками, используя нашу конфигурацию SSH из первой части статьи.
Итак, условия задачи: есть домашний компьютер и ноутубк, оба под управлением Windows 10. Нужно сделать так, чтобы с ноутбука иметь возможность зайти на домашний компьютер по протоколу Remote Desktop из любой точки мира. В состав нашей системы будут входить наш домашний компьютер-сервер Remote Desktop, ноутбук с клиентом Remote Desktop, и сервер SSH. Сервер SSH — единственный компонент, которому требуется глобальный IP-адрес и постоянная доступность. Самый простой вариант, удовлетворяющий этим требованиям, — разместить SSH-сервер в облаке. Яндекс.Облако отлично подходит (в первую очередь за счёт своей ценовой политики), так что будем использовать его. В итоге получается вот так:
Начнём с подготовки нашего домашнего компьютера. Сперва убедимся, что удалённый доступ к нему вообще разрешён. Это можно сделать через вкладку «Удаленный доступ» в дополнительных параметрах системы:
Начиная с апреля 2018 года в Windows 10 среди утилит командной строки уже присутствует ssh-клиент. Это поможет нам меньше отвлекаться на установку разного софта и сразу приступить к делу. Для начала сгенерируем себе ключ для SSH. Откроем командный интерпретатор PowerShell и выполним 'ssh-keygen'. Когда нас спросят о пароле для ключа, оставим его пустым. После генерации ключа выведем его открытую часть на консоль командой 'cat $HOME/.ssh/id_rsa.pub'. Результат выполнения команды пригодится нам для запуска SSH-сервера в облаке. Должно получиться что-то вроде этого:
Нам нужно скопировать закрытую часть ключа SSH на ноутбук. Эта часть ключа лежит в файле '$HOME/.ssh/id_rsa' (без суффикса ".pub"), и мы можем скопировать его как обычный файл. К примеру, используя флешку (предполагаем, что она смонтирована как диск F:)
copy $HOME/.ssh/id_rsa f:Теперь запустим наш SSH-сервер. Создадим виртуальную машину (ВМ) в Яндекс.Облаке. Для наших целей можно выбрать «лёгкую» ВМ с 1 vCPU и 0.5 гигабайта RAM. В разделе сетевых настроек выберем сеть по умолчанию с автоматическим IP-адресом. В раздел «доступ» в качестве логина введём «home», в поле ввода SSH-ключа скопируем то, что вывелось у нас в консоль на предыдущем шаге:
Нажмём «Создать ВМ» и дождёмся завершения. После того, как создание виртуальной машины завершится, нам потребуется узнать её IP-адрес:
IP-адрес нашей виртуальной машины нам понадобится, чтобы запускать SSH-клиент на домашнем компьютере и ноутбуке. Запустим его на компьютере вот таким образом (в этой и следующих командах необходимо заменить 84.201.141.36 на IP-адрес вашей ВМ):
ssh -NR 3389:localhost:3389 home@84.201.141.36
На вопрос о подключении к неизвестному серверу отвечаем «yes». Если затем мы не видим никакого текста на консоли, значит всё прошло отлично. Теперь настроим ноутбук. Скопируем закрытый ключ с нашей флешки:
mkdir -Force $HOME/.ssh
copy f:\id_rsa $HOME/.ssh/id_rsa
И запустим SSH-клиент:
ssh -NL 1025:localhost:3389 home@84.201.141.36
Теперь можно запускать на ноутбуке клиент удалённого доступа к рабочему столу (mstsc.exe), указав в качестве адреса подключения localhost:1025. Ура, работает!
Или почти работает. Если остановить процесс SSH на домашнем компьютере, подключиться станет невозможно. Нам нужно сделать так, чтобы этот процесс автоматически запускался при старте системы, а также перезапускался при разрывах подключения. Этого можно достичь, например, создав PowerShell-скрипт и зарегистрировав его как обязательный для запуска в групповой политике при старте компьютера. Только нужно учесть, что запускаться он будет от имени системного аккаунта, а значит нужно убедиться что системному аккаунту доступен наш SSH-ключ.
Сперва займёмся ключом. Запустим PowerShell от имени администратора и выполним вот такие команды:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa"
icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset
Заодно в этом же окне PowerShell разрешим выполнение скриптов:
Set-ExecutionPolicy RemoteSigned
Теперь создадим собственно скрипт. Откроем наш любимый текстовый редактор (Notepad тоже подойдёт), и напишем вот такой скрипт (не забыв заменить IP-адрес SSH-сервера на тот, что выдан вам Яндексом):
while (1) {
& $(get-command ssh |select -expandproperty Path) `
-i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" `
-o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes `
-NR 3389:localhost:3389 home@84.201.141.36
Start-Sleep -Seconds 15
}
Сохраним скрипт в понравившуюся директорию. Наконец зарегистрируем его для автозапуска. Для этого запустим редактор групповых политик (Win+R > gpedit.msc), и откроем пункты «Конфигурация компьютера» > «Конфигурация Windows» > «Сценарии (запуск/завершение)» > «Автозагрузка». На вкладке «Сценарии PowerShell» воспользуемся кнопкой «Добавить», и укажем путь к нашему сохранённому скрипту.
Аналогичные действия проделаем на ноутбуке. Сперва PowerShell от имени администратора:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa"
icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset
Set-ExecutionPolicy RemoteSigned
Затем в текстовом редакторе подготовим скрипт (он немного отличается от предыдущего, но как и прежде, заменяем IP-адрес на тот, что был выдан вам Яндексом):
while (1) {
& $(get-command ssh |select -expandproperty Path) `
-i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" `
-o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes `
-NL 1025:localhost:3389 home@84.201.141.36
Start-Sleep -Seconds 15
}
Неконец зарегистрируем его для запуска при старте при помощи «gpedit.msc». Перезагрузим компьютер и ноутбук (чтобы убедиться что всё корректно запускается) и вуаля! Теперь наш домашний компьютер и наш ноутбук навеки связаны друг с другом (до тех пор, пока наша виртуальная машина в Яндекс.Облаке включена и доступна).
Ну и?
Ну разве не здорово? В любом кафе, в любом аэропорту можно подключиться к себе домой и посмотреть любимые картинки с котиками. Или порадовать домашних включением 5-й симфонии Бетховена на полную громкость. Или поинтересоваться успехами своей майнинг-фермы. Или посмотреть, что творится дома при помощи веб-камеры. Да мало ли вообще применений у такой возможности «телепортироваться»? Но есть у нашего решения и недостатки.
Во-первых, настройка подключения — не самый простой и приятный процесс. А в случае, если что-то пойдёт не так, отладка еще немного сложнее, чем первоначальная настройка. Само собой, эта проблема решается усидчивостью и терпением, но даже то небольшое количество труда, которое требуется затратить, может вызвать сомнения в целесообразности усилий.
Во-вторых, виртуальная машина в облаке стоит денег. В случае Яндекса тот минимум, на который можно рассчитывать, это 480 рублей в месяц. Это, конечно, не запредельные деньги, но всё-таки свои, заработанные в поте лица. Стоит ли просмотр картинок с котиками этих денег — решать каждому для себя, но очень может быть, что все преимущества нашего решения будут перечёркнуты его ценой.
Ценовой вопрос можно существенно сгладить, разделив расходы с друзьями и единомышленниками. Поскольку виртуальная машина используется для задач, не требующих сколь-либо заметных вычислительных мощностей, падение производительности крайне маловероятно. А экономический эффект — заметен: если арендовать виртуальную машину вдесятером, то каждому придётся заплатить лишь 48 рублей в месяц. Правда, в этом случае гармонию может нарушить вопрос доверия: любой из единомышленников имеет возможность подключиться к компьютеру собрата по SSH-серверу. В случае, когда у всех на аккаунтах установлены надёжные пароли, это не проблема. Но, скажем прямо, надёжный пароль для входа на домашний компьютер — скорее исключение, чем правило.
Продолжение следует
Итак, предположим, что мы собрали 10 единомышленников, настроили всё, как написано выше, и у всех всё работает. Наш клуб любителей картинок с котиками благополучно пользуется возможностью ходить к себе домой через интернет всего за 48 рублей в месяц без регистрации и смс, все довольны и счастливы. Вопрос в том — ограничиваются ли возможности нашей «технологии» лишь котиками и нельзя ли её использовать для чего-то более серьёзного?
Само собой можно. Если заменить в наших рассуждениях «домашний компьютер» на «билд-сервер в облаке», а «ноутбук» на «рабочий компьютер в офисе», мы получаем нечто достойное звания «система доступа к инфраструктуре разработки». А если вместо билд-сервера у нас будет IP-камера, а вместо рабочего компьютера — пост охраны, получаем «систему видеонаблюдения».
В обоих случаях, правда, придётся уделять больше внимания вопросам контроля доступа. В частности, при совместном использовании SSH-сервера несколькими пользователями хотелось бы изолировать этих пользователей друг от друга. А ещё при таком совместном использовании мы вынуждены назначать каждому ресурсу каждого пользователя свой отдельный TCP-порт и запоминать его номер. Адресация по номерам может вскоре стать довольно утомительной, поэтому хотелось бы иметь возможность назначать ресурсам осмысленные названия. Но о том, как улучшить ситуацию, мы поговорим уже в следующей статье.
А пока спасибо за внимание и, пожалуйста, поделитесь своими мыслями в комментариях.
Комментарии (91)
YaDr
26.02.2019 16:15Ситуацию можно улучшить отказавшись от велосипеда с подвывертами и поставив OpenVPN или аналог.
haskeller Автор
26.02.2019 16:21Задачу точно можно решить по другому поставив OpenVPN или аналог. Даже в случае с OpenVPN у нас присутствует необходимость хостить машину-«маршрутизатор» (по совместительству OpenVPN-сервер) где-то в интернете, либо сделать такой машиной домашний компьютер, но тогда нужно обеспечить ему постоянный глобальный адрес. Короче говоря ровно все те же самые соображения.
Смысл статьи в том, чтобыизобрести велосипедпоказать что простые сценарии можно реализовывать и без VPN с помощью средств, которые из коробки есть в большинстве современных ОС.Sworfly
26.02.2019 17:42с помощью средств, которые из коробки есть в большинстве современных ОС.
Большинство современных это Windows 10, Linux, MacOS? Вроде в XP, Vista, 7 не было ssh из коробки.
kmansoft
27.02.2019 12:28Даже в случае с OpenVPN у нас присутствует необходимость хостить машину-«маршрутизатор» (по совместительству OpenVPN-сервер) где-то в интернете
Но и у Вас тоже — маршрутизатор в Интернете с фиксированным адресом.
Я бы подумал про IPSec / GRE, сервер на «маршрутизаторе», подключаться умеют и Win 10 и Linux и Mac. Маршрутизация между клиентами в этом случае не проблема, и провайдеры как правило не блокируют GRE (хотя бы потому что поверх него работает PPTP).
С другой стороны, в Вашем решении меньше дополнительных (= IPSec сервер) программ. Если для Вас именно это является плюсом, ну так и ладно.
jok40
26.02.2019 16:41У OpenVPN или аналогов есть один недостаток: их трафик отлично вычисляется DPI-системами провайдеров и легко запихивается шейпером в тонюсенькую трубочку. То есть вроде и работает, но скорость ниже плинтуса. Попадаются провайдеры, которые это практикуют. А некоторые провайдеры так вообще не напрягаются с DPI, а просто запихивают весь клиентский UDP-трафик в такую трубку. SSH же пока что никто не шейперит. Не считают нужным.
Sworfly
26.02.2019 17:44К слову, OpenVPN неплохо работает и по TCP-IP. А у каких провайдеров vpn режется? Хотелось бы знать что бы не нарваться.
Silvarum
26.02.2019 19:44Нормальный DPI узнает чистый OpenVPN даже, если он работает по TCP (и в том числе косит под HTTPS на 443 порту). Там своеобразный handshake используется. WireShark'а под рукой нет, но вот довольно старая статья на Хакере, где показана разница.
chupasaurus
27.02.2019 09:42Старая статья на Хакере — это хорошо, но есть гораздо более простой документ — код детектора из nDPI.
Sworfly
27.02.2019 10:33Нормальный DPI узнает, а если просто режется UDP, то может и прокатить.
За статью спасибо, посмотрю на досуге.
jok40
27.02.2019 09:31Прямо сейчас я выхожу в интернет именно через такого провайдера. А через какого конкретно — не скажу, уж извините, потому как не готов делиться информацией о своём местонахождении со всем интернетом. Просто имейте в виду, что на данный момент практически любой провайдер имеет техническую возможность ограничить/заблокировать широко известные протоколы VPN. Есть, правда, протокол SSTP — хорошо маскирующийся под HTTPS — не знаю как сейчас у провайдеров дела обстоят с ним.
gecube
27.02.2019 09:41Есть, правда, протокол SSTP — хорошо маскирующийся под HTTPS — не знаю как сейчас у провайдеров дела обстоят с ним.
находят. вычисляют.
sashz
27.02.2019 07:23Китайцы в эти «никто» не входят. SSH cначала режут, потом банят порт, потом целиком ip (China Mobile домашняя оптика). OpenVPN получает бан практически мгновенно.
Pavel7
27.02.2019 11:01OpenVPN или аналог
Насколько я знаю, практически любой vpn-клиент захочет админских прав, как при установке (для сетевого драйвера), так и при подключении (для правки роутинга). Админские права на ssh-клиенте есть далеко не всегда.altman
27.02.2019 21:25OpenVPN при установке добавляет службу OpenVPN Legacy Service (по умолчанию, правда, она не запускается автоматически, надо настроить автозапуск после установки) — тогда клиент можно запускать с правами пользователя и маршруты будут нормально прописываться
Pavel7
27.02.2019 23:36Ну так для установки службы права админа уж точно нужны. Об этом и речь, что не всегда есть возможность поставить OpenVPN, в отличие от ssh-клиента, которому админские права не нужны.
legolegs
26.02.2019 16:46к вам на супер-секретный порт 32167
Эй! Откуда ты узнал-то? Немедленно удали! >:E
Maxlinus
26.02.2019 16:53Пользуясь случаем, спрошу. Есть ли какой нибудь дружелюбный инструмент управления ssh сервером, скажем через web для домохозяек:) без регистрации и смс?
rostislav-zp
27.02.2019 15:20не совсем понял задачу, но если вы имелли ввиду web интерфейс для удаленного сервера, то возможно вам Webmin или ajenti подойдет.
Renatk
26.02.2019 17:27Можно использовать и классический клиент для ssh putty:
blog.afach.de/?p=606
Запуская данный cmd так:
set path=C:\Program Files\PuTTY;C:\Python37\;
c:
cd "C:\Program Files\PuTTY"
python ssh-reconnect.pyMaxlinus
26.02.2019 18:50это не то что нужно, а реконекты хорошо подкрутили в kitty
NickyX3
27.02.2019 09:40еще есть Bitvise SSH Client, там есть и реконнекты, и настройка в gui и портфорварда и сокс и вот это все.
www.bitvise.com/ssh-client
HiroX
26.02.2019 22:48Заодно поставить себе/друга/знакомого на комп и putty и интерпретатор python. Просто чтобы зайти по RDP.
gecube
26.02.2019 20:00Такое работает, только если в протоколе L7 не фигурируют хостнеймы. Ну, например, у Вас веб-сервер на защищаемом сервере, с настроенными virtual hosts. Как тогда будете выкручиваться?
azmar
27.02.2019 01:24Думаю, что нужные хостнеймы он пропишет в hosts на 127.0.0.1, если это винда. А если убунту с локальным dnsmasq то это уже совершенно другая история =)
chupasaurus
27.02.2019 09:44С каких пор локальный dnsmasq станет опрашиваться раньше /etc/hosts?
azmar
27.02.2019 10:21Ну вообще я не об этом, я скорее о том, что локальный днс сервер открывает больше возможностей. Но если вам так очень хочется, то вы можете использовать для этого /etc/nsswitch.conf
chupasaurus
27.02.2019 10:23А я о том, что workflow для локальной подмены A-записей в *nix и Windows одинаковый.
it1804
27.02.2019 12:28Легко. В /etc/hosts (c:\Windows\System32\drivers\etc\hosts) добавить 127.0.0.1 my.any.host
В браузере my.any.host Если сертификат валидный, и с ним нет проблем. Всегда так делаюgecube
27.02.2019 13:33Угу, прекрасное решение. Для начала нужно обладать админскими правами, чтобы это сделать. Вторая история, что это работает «насовсем». Либо нужно костылить скрипты, которые будут эти доменные имена прописывать в нужный момент времени. И третий момент, что если на той стороне веб-приложение, которое редиректит (и должно знать свой адрес), то редирект может сломаться (например, перешли my.any.host:444, т.к. порт 443 висит на другом сервисе, а приложуха думает, что она на my.any.host и строит редирект в my.any.host/my_page.html).
Я к тому, что ситуации бывают разные… и нужны разные подходы. Но то, что описали — имеет право на существование.
И еще раз доказывает, что NAT и IPv4 адреса ни от чего не защищают толком…
HiroX
26.02.2019 22:46-1Меня видимо одного посетил вопрос «это все нужно сделать, чтобы не брать у провайдера внешний ip?» Даже у ОпСоСов реально выпросить статичные внешние ip (от имени ИП, разумеется).
Описанная в статье игра тем более не стоит свеч. Это неудобно (привет wifi с реконнектами), это медленнее (латенси никуда не пропадает).
«рано или поздно к вам на супер-секретный порт 32167 прилетит TCP SYN родом из китайской деревушки» миллионы серверов работают с открытым стандартным портом rdp. да, брутят. брутят в основном учетную запись «Администратор», которая по умолчанию отключена. ЗаDos'ят? бросьте, кому нужны.Kozel-007
27.02.2019 09:56+1То есть ИП зарегистрировать (который больше ни для чего не нужен) — проще и дешевле?
ffs
27.02.2019 10:31В задаче, описанной в статье — да. Белый ИП стоит 50-100р в месяц, яндекс облако почти 500р. Это как за еще одно подключение заплатить. Не вижу смысла.
TonyLorencio
27.02.2019 10:41У некоторых операторов проводных интернетов (в ряде регионов) нет такой услуги как белый IP для физлиц — только для юриков
NoRegrets
27.02.2019 12:00Конечно проще и дешевле зарегистрировать ИП. Вместо скачивания и установки ссш сервера и нудной правки конфигов, набираешь
> cmd install ya-mamkin-predprinimatel && cmd install opsos-static-ip
и все сразу начинает работать. А что бы не платить в фонды и налоги, можно жить под чужим именем.Pavel7
27.02.2019 12:11На самом деле, стать у мамки предпринимателем сейчас действительно можно через cmd, без посещения налоговой, если есть квалифицированная ЭЦП.
zetroot
27.02.2019 15:21Однозначно не дешевле — за год, даже при «нулевой» отчётности, надо заплатить взносы «за себя», а это 32+ т.р.
remzalp
27.02.2019 12:50Ок, в дорогом продакшене лучше уже платить деньги.
Пример встречной ситуации — небольшая компания снимает офис в небольшом бизнес-центре, где благодаря монополизму местный "провайдер" вообще не чешется на предоставление каких-либо услуг кроме "исходящий интернет для сотрудников".
Как, даже при очень большом желании админу маленькой компании пробуриться через NAT/PAT снаружи до своего любимого сервера?
Тимвьювер? Впн наружу?
Если смотреть за пределы облака яндекса, то цены будут радовать заметно сильнее. Но в любом случае это не отменяет потребности настраивать инфраструктуру на внешнем сервере.
Так почему бы при наличии уже действующего внешнего сервера (тот же хостинг) не использовать побочный бонус?
azmar
27.02.2019 00:58+2Скажите, а почему яндекс облако? Ведь обычная вдс будет стоить намного дешевле, например один из популярных российских вдс хостингов предлагает конфигурацию с 1 ядром и гигабайтом оперативы за 160 рублей в месяц.
Ну и да, на этом же вдс вполне можно поднять впн сервер и иметь гораздо больше возможностейlgorSL
27.02.2019 03:25Я в google cloud видел какую-то совсем стоковую машинку (типа 0.5гб и 1-2 ядер), которую можно бесплатно использовать 31 день в месяц — типа одну такую машинку можно держать всегда включенной. (да и если небесплатно использовать — цена явно гуманннее, чем у яндекса.)
P.s. Более интересным выглядит вариант не использовать внешний сервер, ну или использовать его только как точку рандеву, чтобы пробиться сквозь nat.
petrovichtim
27.02.2019 10:52Гугловой я бы побоялся пользоваться из-за паранои, на Digital Ocean минимальная машинка за 5$ в месяц
balamutang
27.02.2019 18:57на scaleway виртуалка 2 евро/мес (x86/1гб ram/25gb ssd), а ARM и того дешевле.
xeon
27.02.2019 10:40Да-да. За 200 в месяц можно взять vscale. Или просто белый IP домой у своего провайдера.
А если рассматривать Европу, то и за 1 EUR /mo можно получить VPS с белым ipv4ABATAPA
27.02.2019 12:07Да, вот была Aruba за 1€, да больше нету. Хорошо хоть тем, кто успел, оставили тариф.
И скорость с ними отличная, я даже по NFS 1.5GB/min имею.xeon
27.02.2019 12:10Закончилась, да? Я на ней так и сижу. И ещё давно раньше была раздача халявы и за $1/mo у меня ещё и белый IP в штатах.
haskeller Автор
27.02.2019 10:42И правда. Действительно, так существенно дешевле. Каких-то особенных причин использовать именно облако а не ВДС нет. Век живи — век учись.
FSA
01.03.2019 00:58Знаю я одного такого. Но у него по правилам запрещено ставить прокси, VPN и прочее. Так что могут и забанить в самый неподходящий момент. А вот в Европе можно и за пол яндексовской цены взять для таких целей, но пинг будет, понятное дело почему, хуже.
immaculate
27.02.2019 02:47+1Комментарий не по сути статьи, а мелкое замечание:
В shell вместо$HOMEможно использовать~.
Намного короче и удобнее печатать:
cat ~/.ssh/id_rsa.pubвместо громоздкого трудно печатаемого из-за необходимости удерживать Shiftcat $HOME/.ssh/id_rsa.pub.
lubezniy
27.02.2019 06:42Ещё в расход надо бы добавить Windows Professional на домашней машине: предустановлена таки чаще Home, у которой возможность подключения к ней по rdp отключена.
xeon
27.02.2019 10:35github.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.
achekalin
27.02.2019 09:41В общем, для многих вариант поставить TV на машину будет более работающим и логичным. Тем более если тебе нужно, именно что, зайти на машину, включить Бетховена, и проведать свою майнинг-ферму. Собственно, даже TV стоит недорого, не говоря, что есть (для личного пользования) и некоторое кол-во других решений.
Я не ратую за замену ssh на tv, я про прямое решение задачи. Хочешь поуправлять компом — настрой управление компом, а не страдай с VPS-кой!jok40
27.02.2019 10:36Teamviewer гонит весь трафик через свои сервера. Я бы не стал его использовать для доступа к своему компьютеру на постоянной основе именно в плане безопасности. Опять же насчёт статьи: насколько я понял, она про ssh и про то, что его можно использовать не только по прямому назначению. А доступ с компа на комп через VPS приведён в качестве примера такого использования.
xeon
27.02.2019 10:39«даже TV стоит недорого» — 2000 в месяц?
Ну и в целом пока что купить белый IP — это 200р. в месяц, что позволяет и без извратов с VPS делать. А для извратов можно и за 1 EUR взять сервер с белым IP в Европе.
Maxlinus
27.02.2019 14:53дешевле VPS за 55р/месяц, а через него уже что угодно настраивай, ssh+vnc например
achekalin
27.02.2019 18:21А вы на что отвечали: на фразу «Я не ратую за замену ssh на tv, я про прямое решение задачи»?
P.S. И, конечно, vnc — никак не замена tv. Ну вот как ни крутите. Я про набор фич и качество картинки… Но, конечно, по соотношению «цена/качество» tv проиграет любому бесплатному продукту, тут тоже не о чем спорить.
Pavel7
27.02.2019 10:41В обратном режиме слушающий TCP-порт открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента. Пригождается такое редко, но, как правило, очень метко.
На самом деле, пригождается такое очень часто, когда вам нужно сделать себе нормальный RDP-доступ к машине, которая расположена в какой-нибудь корпоративной сети с драконовскими политиками удаленного подключения.
На машине запускается ssh-клиент (+ cntlm, если корпоративная прокся не разрешает basic) и на ssh-сервер публикуется localhost:3389 от машины (не забудьте только разрешить в настройках ssh-сервера ssh-клиентам указывать на каком интерфейсе публиковать, иначе порт опубликуется на всех). Кстати, putty и kitty для этого сценария не подходят — у них есть странный глюк, что rdp-подключение пройдет, но тут же отвалится. А вот bitvise ssh client исполняет такое без проблем.Maxlinus
27.02.2019 14:57github.com/maxlinus/BrynhildrHelpdesk, использую 3 связки: br+kitty, vnc+kitty, rdp+kitty, глюков не наблюдал
xeleos
27.02.2019 12:19Ну вы конечно и придумали. А я просто настроил DDNS бесплатный и перебросил порт на комп.
haskeller Автор
27.02.2019 12:24Всё классно, единственный нюанс — открытость этого порта не только для вас, но и для любого пользователя из интернета. При наличии уязвимости в сервере RDP — ваш компьютер уже не совсем ваш.
В предложеной экзотической схеме для получения доступа к вашему компьютеру требуется уже две уязвимости — одна в сервере SSH, другая в сервере RDP.
Ну и не всегда сейчас провайдер даёт конечному оборудованию глобальный IP-адрес, пусть и динамический.
Makaronin
27.02.2019 12:27Я конечно могу сильно ошибаться, но в данном варианте использования не проще было «завести» Hamachi на дескотопе и просто добавить необходимые устройства в сеть. Да, в бесплатной версии там есть ограничения, но много кому в данном сценарии использования необходимо больше машин? По поводу запуска стороннего приложения на каждой из машин участников сети, не расцениваю это как большой минус.
Cerberuser
27.02.2019 16:09А если «на каждой из заранее неизвестного множества машин» (упомянутый выше в комментах случай «зайти от друга»)?
Makaronin
27.02.2019 17:44Как минимум для «зайти от друга» вам необходимо будет иметь в наличии ваш RSA ключ и иметь " в голове" адресс связующего сервера. Что мешает иметь на флешке клиент hamachi?
Да и сорить секретными ключами на «неизвестном множестве» не хочется. а если начинать автоматизировать дело по их контролю, то тут мне кажется мы выходим за рамки «простого способа»
VSOP_juDGe
27.02.2019 14:18+1Я для решения этой задачи использую ZeroTier. Не нужны внешние сервера, все устройства получаются в одной локалке, где бы они не находились.
Materializator
28.02.2019 15:51Извините чайника, но бесплатные лимиты AWS тоже позволят развернуть такую инфраструктуру?
Sunny-s
28.02.2019 16:09Сначала порадовался тому, что и яндекс стал давать облачные сервера в аренду, а потом посмотрел на цену и понял, почему я об этом до сих пор не знал. Облачный сервер с такими параметрами реально купить в 8-10 раз дешевле в очень многих местах. Смысл предложения яндекса не очень понятен, цена похожа на заградительную.
gecube
28.02.2019 16:28Потому что нужно сравнивать услуги одного класса. Условно — какой-нибудь хостинг типа Hetzner/timeweb/flops вообще не про то же самое, что и Яндекс. Одно — тупые VDS на непонятном оборудовании, второе — виртуальная инфраструктура с широким спектром доп. услуг. Понятно, что они могут быть не нужны, поэтому первые и выживают.
Sworfly
А в чем смысл использования ssh в этой задаче? ИМХО, намного проще воспользоваться скриптом настройки vpn и работать через него. Это упростит настройку клиентов(скачать openvpn, установить, подкинуть в нужный каталог ключ и прописать в автозапуск) и уменьшит возможные последствия для арендатора сервера — ssh кроме проброса порта позволяет создать socks прокси и кто-то этим может воспользоваться для «обхода блокировок».
В случае использования vpn можно настроить правила маршрутизации трафика между машинами. Например, пользователь А может сходить на свою домашнюю машину и на локальный сервер CS 1.6, а пользователь Б только на домашнюю машину.
haskeller Автор
Принципиально такая поделка на SSH эквивалента VPN, разница лишь в том, что адресация по паре «IP адрес: порт» фактически заменена на адресацию просто по номеру порта (ну и действительно процедура настройки автозапуска клиентов сложнее чем в случае OpenVPN). Есть незначительная удобная мелочь в том что для подключения к дому с какого-то третьего компьютера SSH можно запустить не имея админских прав (в отличие от OpenVPN). Ну и сервер настраивать однозначно проще (нужно ровно ничего не делать сверх запуска ВМ в облаке).
Про socks-прокси и политики — согласен. В следующей статье как раз планировал попиарить опенсорсную поделку, которая позволяет и всё кроме порт форвардинга запретить и политики доступа написать.
Sworfly
С разницей в настройке сервера с помощью опенсорсного скрипта можно поспорить — скрипт сам устанавливает(лучше конечно посмотреть что он поставит или попросить кого-то) все что нужно для работы openvpn, а после этого работает мастер, с помощью которого можно как добавить пользователя, так и удалить, что проще чем искать нужный ключ в authorized_keys.
Закрыть трафик во внешку можно одним исправлением конфига openvpn. Настроить маршруты сложнее, но в большинстве случаев это и не нужно.
Запуск с третьего компьютера без прав… а надо ли? Если кто-то запретил создавать подключения, то зачем нарываться на неприятности? А если не запрещал и это просто компьютер у друга, то можно попросить запустить клиента с нужными правами.
ЗЫ. А вот про поделку для настройки доступа было бы интересно почитать.
ЗЫЗЫ. ЕМНИП, когда OpenShift был бесплатным, то в нем скорость ssh проброса сильно резалась. Админить систему можно было, а вот закинуть большой файл уже сложнее.
sukhodolin
Проблема с OpenVPN в том, что «из коробки» это решение для выдачи доступа во всю сеть, а не к отдельным сервисам в этой сети. Можно, конечно, нагородить кучу правил в таблице маршрутизации (или даже iptables на стороне сервера VPN), но чувствуется несоответствие инструментария (управление сетью на Layer 4) предметной области задачи (Layer 7) в случае, когда нужно раздать доступ именно к сервисам (sql, web, etc), а не обеспечить прохождение произвольных пакетов из одной подсети в другую.
Например, такой сценарий: компания хочет дать временной доступ (другой компании или контрактору) к базу данных или ко внутреннему веб-приложению. Это можно сделать одной командой SSH, запущенной из корпоративной сети, для соединения с неким внешним SSH сервером (управляемым контрактором). Никакого дополнительного софта, доступ по самому минимуму (фиксированный IP:port) и никаких лишних дыр в безопасноти. С OpenVPN пришлось бы изрядно поколхозить для достижения такого же результата…
Sworfly
Да, для такого сценария SSH удобнее, полностью согласен, но для решения задачи из поста или если нужно разрешить десяток портов, а к остальным запретить доступ — увольте =)
Думаю, настроить iptables и openvpn через web-морду или консоль будет быстрее создания нового пользователя и прописывания нужных разрешений для проброса в конфиге.
gecube
С точки зрения безопасности — то, что Вы предлагаете фигня, т.к. обычно требуется поддержка со стороны приложения. Например, нужен доступ в БД. А эта БД — какой-то большой Oracle или Postgres, где все данные компании. Получается, нужно еще создавать вьюху и создавать отдельного пользователя именно на уровне самой БД.
REST сервисы можно загнать за nginx и на уровне него разрулить какой юзер должен иметь доступ куда.
Это не отменяет ограничений по IP и портам, но, как говорится, безопасность — это комплекс мер.
Вопрос в том, что все эти меры должны быть доступны из какой-то единой панели…