VPN без VPN или рассказ об нетрадиционном использовании SSH

По данным ssh.com и Wikipedia, первая версия и реализация протокола SSH увидела свет в 1995 году. Задачей автора было разработать безопасную альтернативу использовавшимся тогда для удалённого администрирования rlogin, telnet и rsh. Любопытно, что появлению протокола SSH поспособствовал инцидент информационной безопасности, в результате которого злоумышленник собрал внушительную базу логинов/паролей от серверов, просто прослушивая университетскую сеть и выделяя пакеты аутентификации (пары логин/пароль в них передавались в незашифрованном виде).

Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизован IETF в 2006 году. С тех пор он успел стать де-факто стандартом для удалённого управления системами с текстовой консолью. Помимо собственно текстовой консоли в протоколе предусмотрена масса других полезных функций, таких как передача файлов и переадресация портов. Именно о переадресации портов (port forwarding) и её не слишком очевидном применении пойдёт речь в этой статье.

В протоколе SSH предусмотрено два режима переадресации портов — прямой и обратный. Прямой режим позволяет открыть слушающий TCP-порт на стороне SSH-клиента и переадресовать все подключения к этому порту на сторону сервера.

image

К примеру, если на нашем SSH-сервере выполняется сервер удалённого рабочего стола (Remote Desktop, RDS), мы можем использовать протокол SSH, чтобы подключиться к этому серверу, даже если прямое сетевое подключение невозможно (к примеру, заблокировано межсетевым экраном). Вот так:

image

Второй режим переадресации портов — обратный — позволяет поменять местами роли SSH-сервера и клиента (применительно к переадресуемому порту). В обратном режиме слушающий TCP-порт открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента. Пригождается такое редко, но, как правило, очень метко.

image

Комбинируя эти два режима и наш пример с сервером удалённого рабочего стола можно получить вот такую конфигурацию:

image

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

  1. Единственное, что требуется от сети, чтобы такая схема работала корректно, — обеспечить постоянство сетевого адреса узла, где размещён SSH-сервер. Узлы, на которых выполняются сервер и клиент RDS, могут менять свои сетевые адреса хоть каждую минуту (либо вообще могут иметь адреса в частной сети, нам требуется лишь исходящий NAT, что часто и подразумевается под формулировкой «подключение к интернету»).
  2. Несмотря на то, что для нас самих 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-сервер в облаке. Яндекс.Облако отлично подходит (в первую очередь за счёт своей ценовой политики), так что будем использовать его. В итоге получается вот так:

image

Начнём с подготовки нашего домашнего компьютера. Сперва убедимся, что удалённый доступ к нему вообще разрешён. Это можно сделать через вкладку «Удаленный доступ» в дополнительных параметрах системы:

image

Начиная с апреля 2018 года в Windows 10 среди утилит командной строки уже присутствует ssh-клиент. Это поможет нам меньше отвлекаться на установку разного софта и сразу приступить к делу. Для начала сгенерируем себе ключ для SSH. Откроем командный интерпретатор PowerShell и выполним 'ssh-keygen'. Когда нас спросят о пароле для ключа, оставим его пустым. После генерации ключа выведем его открытую часть на консоль командой 'cat $HOME/.ssh/id_rsa.pub'. Результат выполнения команды пригодится нам для запуска SSH-сервера в облаке. Должно получиться что-то вроде этого:

image

Нам нужно скопировать закрытую часть ключа SSH на ноутбук. Эта часть ключа лежит в файле '$HOME/.ssh/id_rsa' (без суффикса ".pub"), и мы можем скопировать его как обычный файл. К примеру, используя флешку (предполагаем, что она смонтирована как диск F:)

copy $HOME/.ssh/id_rsa f:\

Теперь запустим наш SSH-сервер. Создадим виртуальную машину (ВМ) в Яндекс.Облаке. Для наших целей можно выбрать «лёгкую» ВМ с 1 vCPU и 0.5 гигабайта RAM. В разделе сетевых настроек выберем сеть по умолчанию с автоматическим IP-адресом. В раздел «доступ» в качестве логина введём «home», в поле ввода SSH-ключа скопируем то, что вывелось у нас в консоль на предыдущем шаге:

image

Нажмём «Создать ВМ» и дождёмся завершения. После того, как создание виртуальной машины завершится, нам потребуется узнать её IP-адрес:

image

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» воспользуемся кнопкой «Добавить», и укажем путь к нашему сохранённому скрипту.

image

Аналогичные действия проделаем на ноутбуке. Сперва 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-порт и запоминать его номер. Адресация по номерам может вскоре стать довольно утомительной, поэтому хотелось бы иметь возможность назначать ресурсам осмысленные названия. Но о том, как улучшить ситуацию, мы поговорим уже в следующей статье.

А пока спасибо за внимание и, пожалуйста, поделитесь своими мыслями в комментариях.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 94

    +3
    А в чем смысл использования ssh в этой задаче? ИМХО, намного проще воспользоваться скриптом настройки vpn и работать через него. Это упростит настройку клиентов(скачать openvpn, установить, подкинуть в нужный каталог ключ и прописать в автозапуск) и уменьшит возможные последствия для арендатора сервера — ssh кроме проброса порта позволяет создать socks прокси и кто-то этим может воспользоваться для «обхода блокировок».
    В случае использования vpn можно настроить правила маршрутизации трафика между машинами. Например, пользователь А может сходить на свою домашнюю машину и на локальный сервер CS 1.6, а пользователь Б только на домашнюю машину.
      +3
      Принципиально такая поделка на SSH эквивалента VPN, разница лишь в том, что адресация по паре «IP адрес: порт» фактически заменена на адресацию просто по номеру порта (ну и действительно процедура настройки автозапуска клиентов сложнее чем в случае OpenVPN). Есть незначительная удобная мелочь в том что для подключения к дому с какого-то третьего компьютера SSH можно запустить не имея админских прав (в отличие от OpenVPN). Ну и сервер настраивать однозначно проще (нужно ровно ничего не делать сверх запуска ВМ в облаке).

      Про socks-прокси и политики — согласен. В следующей статье как раз планировал попиарить опенсорсную поделку, которая позволяет и всё кроме порт форвардинга запретить и политики доступа написать.
        0
        С разницей в настройке сервера с помощью опенсорсного скрипта можно поспорить — скрипт сам устанавливает(лучше конечно посмотреть что он поставит или попросить кого-то) все что нужно для работы openvpn, а после этого работает мастер, с помощью которого можно как добавить пользователя, так и удалить, что проще чем искать нужный ключ в authorized_keys.
        Закрыть трафик во внешку можно одним исправлением конфига openvpn. Настроить маршруты сложнее, но в большинстве случаев это и не нужно.
        Запуск с третьего компьютера без прав… а надо ли? Если кто-то запретил создавать подключения, то зачем нарываться на неприятности? А если не запрещал и это просто компьютер у друга, то можно попросить запустить клиента с нужными правами.
        ЗЫ. А вот про поделку для настройки доступа было бы интересно почитать.
        ЗЫЗЫ. ЕМНИП, когда OpenShift был бесплатным, то в нем скорость ssh проброса сильно резалась. Админить систему можно было, а вот закинуть большой файл уже сложнее.
        +3
        Проблема с OpenVPN в том, что «из коробки» это решение для выдачи доступа во всю сеть, а не к отдельным сервисам в этой сети. Можно, конечно, нагородить кучу правил в таблице маршрутизации (или даже iptables на стороне сервера VPN), но чувствуется несоответствие инструментария (управление сетью на Layer 4) предметной области задачи (Layer 7) в случае, когда нужно раздать доступ именно к сервисам (sql, web, etc), а не обеспечить прохождение произвольных пакетов из одной подсети в другую.

        Например, такой сценарий: компания хочет дать временной доступ (другой компании или контрактору) к базу данных или ко внутреннему веб-приложению. Это можно сделать одной командой SSH, запущенной из корпоративной сети, для соединения с неким внешним SSH сервером (управляемым контрактором). Никакого дополнительного софта, доступ по самому минимуму (фиксированный IP:port) и никаких лишних дыр в безопасноти. С OpenVPN пришлось бы изрядно поколхозить для достижения такого же результата…
          0
          Да, для такого сценария SSH удобнее, полностью согласен, но для решения задачи из поста или если нужно разрешить десяток портов, а к остальным запретить доступ — увольте =)
          Думаю, настроить iptables и openvpn через web-морду или консоль будет быстрее создания нового пользователя и прописывания нужных разрешений для проброса в конфиге.
            0
            С точки зрения безопасности — то, что Вы предлагаете фигня, т.к. обычно требуется поддержка со стороны приложения. Например, нужен доступ в БД. А эта БД — какой-то большой Oracle или Postgres, где все данные компании. Получается, нужно еще создавать вьюху и создавать отдельного пользователя именно на уровне самой БД.
            REST сервисы можно загнать за nginx и на уровне него разрулить какой юзер должен иметь доступ куда.
            Это не отменяет ограничений по IP и портам, но, как говорится, безопасность — это комплекс мер.
            Вопрос в том, что все эти меры должны быть доступны из какой-то единой панели…
          +5
          Ситуацию можно улучшить отказавшись от велосипеда с подвывертами и поставив OpenVPN или аналог.
            +6
            Задачу точно можно решить по другому поставив OpenVPN или аналог. Даже в случае с OpenVPN у нас присутствует необходимость хостить машину-«маршрутизатор» (по совместительству OpenVPN-сервер) где-то в интернете, либо сделать такой машиной домашний компьютер, но тогда нужно обеспечить ему постоянный глобальный адрес. Короче говоря ровно все те же самые соображения.

            Смысл статьи в том, чтобы изобрести велосипед показать что простые сценарии можно реализовывать и без VPN с помощью средств, которые из коробки есть в большинстве современных ОС.
              +2
              с помощью средств, которые из коробки есть в большинстве современных ОС.

              Большинство современных это Windows 10, Linux, MacOS? Вроде в XP, Vista, 7 не было ssh из коробки.
                0
                Вы незаслужено обидели фанатов OS/2 Convenience Pack 2. Они тоже считают свою систему современной :)
                  0
                  Ого! Не думал, что ей кто-то еще пользуется =)
                    –1
                    Черт! Забыл добавить — Бугагашенька!
              • UFO just landed and posted this here
                  0
                  GRE не через всякий NAT пройдет, старенький он. openvpn/wireguard лучше
                +1
                У OpenVPN или аналогов есть один недостаток: их трафик отлично вычисляется DPI-системами провайдеров и легко запихивается шейпером в тонюсенькую трубочку. То есть вроде и работает, но скорость ниже плинтуса. Попадаются провайдеры, которые это практикуют. А некоторые провайдеры так вообще не напрягаются с DPI, а просто запихивают весь клиентский UDP-трафик в такую трубку. SSH же пока что никто не шейперит. Не считают нужным.
                  0
                  К слову, OpenVPN неплохо работает и по TCP-IP. А у каких провайдеров vpn режется? Хотелось бы знать что бы не нарваться.
                    +2
                    Нормальный DPI узнает чистый OpenVPN даже, если он работает по TCP (и в том числе косит под HTTPS на 443 порту). Там своеобразный handshake используется. WireShark'а под рукой нет, но вот довольно старая статья на Хакере, где показана разница.
                      +1
                      Старая статья на Хакере — это хорошо, но есть гораздо более простой документ — код детектора из nDPI.
                        0
                        Нормальный DPI узнает, а если просто режется UDP, то может и прокатить.
                        За статью спасибо, посмотрю на досуге.
                        +3

                        Например в Китае. В командировках по openvpn попасть на машину в России не представляется возможным. А по ssh — работает.

                          +1
                          А по ssh — работает.

                          это если трафик не гнать
                          0
                          Прямо сейчас я выхожу в интернет именно через такого провайдера. А через какого конкретно — не скажу, уж извините, потому как не готов делиться информацией о своём местонахождении со всем интернетом. Просто имейте в виду, что на данный момент практически любой провайдер имеет техническую возможность ограничить/заблокировать широко известные протоколы VPN. Есть, правда, протокол SSTP — хорошо маскирующийся под HTTPS — не знаю как сейчас у провайдеров дела обстоят с ним.
                            0
                            Есть, правда, протокол SSTP — хорошо маскирующийся под HTTPS — не знаю как сейчас у провайдеров дела обстоят с ним.

                            находят. вычисляют.
                          0
                          Китайцы в эти «никто» не входят. SSH cначала режут, потом банят порт, потом целиком ip (China Mobile домашняя оптика). OpenVPN получает бан практически мгновенно.
                          0
                          OpenVPN или аналог


                          Насколько я знаю, практически любой vpn-клиент захочет админских прав, как при установке (для сетевого драйвера), так и при подключении (для правки роутинга). Админские права на ssh-клиенте есть далеко не всегда.
                            0

                            OpenVPN при установке добавляет службу OpenVPN Legacy Service (по умолчанию, правда, она не запускается автоматически, надо настроить автозапуск после установки) — тогда клиент можно запускать с правами пользователя и маршруты будут нормально прописываться

                              0
                              Ну так для установки службы права админа уж точно нужны. Об этом и речь, что не всегда есть возможность поставить OpenVPN, в отличие от ssh-клиента, которому админские права не нужны.
                          +1
                          ssh же умеет делать как бы свой «vpn» :) habr.com/ru/post/87197
                            0
                            к вам на супер-секретный порт 32167
                            Эй! Откуда ты узнал-то? Немедленно удали! >:E
                              0
                              Пользуясь случаем, спрошу. Есть ли какой нибудь дружелюбный инструмент управления ssh сервером, скажем через web для домохозяек:) без регистрации и смс?
                                +2
                                А чего им управлять-то? Ключи сгенерировал да запустил.
                                  0
                                  создание пользователей, генерация ключей, управление туннелями, еще бы активность этих самых туннелей.
                                  Одно решение нашёл (persistentssh), ток оно платное :(
                                  0
                                  не совсем понял задачу, но если вы имелли ввиду web интерфейс для удаленного сервера, то возможно вам Webmin или ajenti подойдет.
                                  0
                                  Можно использовать и классический клиент для 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.py
                                    0
                                    это не то что нужно, а реконекты хорошо подкрутили в kitty
                                      0
                                      еще есть Bitvise SSH Client, там есть и реконнекты, и настройка в gui и портфорварда и сокс и вот это все.
                                      www.bitvise.com/ssh-client
                                      0
                                      Заодно поставить себе/друга/знакомого на комп и putty и интерпретатор python. Просто чтобы зайти по RDP.
                                      0
                                      Такое работает, только если в протоколе L7 не фигурируют хостнеймы. Ну, например, у Вас веб-сервер на защищаемом сервере, с настроенными virtual hosts. Как тогда будете выкручиваться?
                                        0
                                        Думаю, что нужные хостнеймы он пропишет в hosts на 127.0.0.1, если это винда. А если убунту с локальным dnsmasq то это уже совершенно другая история =)
                                          0
                                          С каких пор локальный dnsmasq станет опрашиваться раньше /etc/hosts?
                                            0
                                            Ну вообще я не об этом, я скорее о том, что локальный днс сервер открывает больше возможностей. Но если вам так очень хочется, то вы можете использовать для этого /etc/nsswitch.conf
                                              0
                                              А я о том, что workflow для локальной подмены A-записей в *nix и Windows одинаковый.
                                          0
                                          Легко. В /etc/hosts (c:\Windows\System32\drivers\etc\hosts) добавить 127.0.0.1 my.any.host
                                          В браузере my.any.host Если сертификат валидный, и с ним нет проблем. Всегда так делаю
                                            0
                                            Угу, прекрасное решение. Для начала нужно обладать админскими правами, чтобы это сделать. Вторая история, что это работает «насовсем». Либо нужно костылить скрипты, которые будут эти доменные имена прописывать в нужный момент времени. И третий момент, что если на той стороне веб-приложение, которое редиректит (и должно знать свой адрес), то редирект может сломаться (например, перешли my.any.host:444, т.к. порт 443 висит на другом сервисе, а приложуха думает, что она на my.any.host и строит редирект в my.any.host/my_page.html).
                                            Я к тому, что ситуации бывают разные… и нужны разные подходы. Но то, что описали — имеет право на существование.
                                            И еще раз доказывает, что NAT и IPv4 адреса ни от чего не защищают толком…
                                          +1
                                          Меня видимо одного посетил вопрос «это все нужно сделать, чтобы не брать у провайдера внешний ip?» Даже у ОпСоСов реально выпросить статичные внешние ip (от имени ИП, разумеется).
                                          Описанная в статье игра тем более не стоит свеч. Это неудобно (привет wifi с реконнектами), это медленнее (латенси никуда не пропадает).

                                          «рано или поздно к вам на супер-секретный порт 32167 прилетит TCP SYN родом из китайской деревушки» миллионы серверов работают с открытым стандартным портом rdp. да, брутят. брутят в основном учетную запись «Администратор», которая по умолчанию отключена. ЗаDos'ят? бросьте, кому нужны.
                                            +1
                                            То есть ИП зарегистрировать (который больше ни для чего не нужен) — проще и дешевле?
                                              0
                                              В задаче, описанной в статье — да. Белый ИП стоит 50-100р в месяц, яндекс облако почти 500р. Это как за еще одно подключение заплатить. Не вижу смысла.
                                                0

                                                У некоторых операторов проводных интернетов (в ряде регионов) нет такой услуги как белый IP для физлиц — только для юриков

                                                  0
                                                  Конечно проще и дешевле зарегистрировать ИП. Вместо скачивания и установки ссш сервера и нудной правки конфигов, набираешь
                                                  > cmd install ya-mamkin-predprinimatel && cmd install opsos-static-ip
                                                  и все сразу начинает работать. А что бы не платить в фонды и налоги, можно жить под чужим именем.
                                                    +1
                                                    На самом деле, стать у мамки предпринимателем сейчас действительно можно через cmd, без посещения налоговой, если есть квалифицированная ЭЦП.
                                                  0
                                                  Однозначно не дешевле — за год, даже при «нулевой» отчётности, надо заплатить взносы «за себя», а это 32+ т.р.
                                                  0

                                                  Ок, в дорогом продакшене лучше уже платить деньги.
                                                  Пример встречной ситуации — небольшая компания снимает офис в небольшом бизнес-центре, где благодаря монополизму местный "провайдер" вообще не чешется на предоставление каких-либо услуг кроме "исходящий интернет для сотрудников".


                                                  Как, даже при очень большом желании админу маленькой компании пробуриться через NAT/PAT снаружи до своего любимого сервера?
                                                  Тимвьювер? Впн наружу?


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

                                                  0

                                                  Виндоюзерам дали ссш, и они начали делать костыли возрастом лет 10-15)

                                                    +2
                                                    Скажите, а почему яндекс облако? Ведь обычная вдс будет стоить намного дешевле, например один из популярных российских вдс хостингов предлагает конфигурацию с 1 ядром и гигабайтом оперативы за 160 рублей в месяц.

                                                    Ну и да, на этом же вдс вполне можно поднять впн сервер и иметь гораздо больше возможностей
                                                      +1

                                                      Я в google cloud видел какую-то совсем стоковую машинку (типа 0.5гб и 1-2 ядер), которую можно бесплатно использовать 31 день в месяц — типа одну такую машинку можно держать всегда включенной. (да и если небесплатно использовать — цена явно гуманннее, чем у яндекса.)


                                                      P.s. Более интересным выглядит вариант не использовать внешний сервер, ну или использовать его только как точку рандеву, чтобы пробиться сквозь nat.

                                                        0
                                                        Гугловой я бы побоялся пользоваться из-за паранои, на Digital Ocean минимальная машинка за 5$ в месяц
                                                          0
                                                          на scaleway виртуалка 2 евро/мес (x86/1гб ram/25gb ssd), а ARM и того дешевле.
                                                            0
                                                            Спасибо, надо прицениться.
                                                        0
                                                        Да-да. За 200 в месяц можно взять vscale. Или просто белый IP домой у своего провайдера.
                                                        А если рассматривать Европу, то и за 1 EUR /mo можно получить VPS с белым ipv4
                                                          0
                                                          Да, вот была Aruba за 1€, да больше нету. Хорошо хоть тем, кто успел, оставили тариф.
                                                          И скорость с ними отличная, я даже по NFS 1.5GB/min имею.
                                                            0
                                                            Закончилась, да? Я на ней так и сижу. И ещё давно раньше была раздача халявы и за $1/mo у меня ещё и белый IP в штатах.
                                                            0
                                                            у арубы? проверь данные — закончилась халява :(
                                                              0
                                                              Да, реально :(
                                                            0
                                                            И правда. Действительно, так существенно дешевле. Каких-то особенных причин использовать именно облако а не ВДС нет. Век живи — век учись.
                                                              0
                                                              Знаю я одного такого. Но у него по правилам запрещено ставить прокси, VPN и прочее. Так что могут и забанить в самый неподходящий момент. А вот в Европе можно и за пол яндексовской цены взять для таких целей, но пинг будет, понятное дело почему, хуже.
                                                              +3

                                                              Комментарий не по сути статьи, а мелкое замечание:
                                                              В shell вместо $HOME можно использовать ~.


                                                              Намного короче и удобнее печатать: cat ~/.ssh/id_rsa.pub вместо громоздкого трудно печатаемого из-за необходимости удерживать Shift cat $HOME/.ssh/id_rsa.pub.

                                                                +1
                                                                Ещё в расход надо бы добавить Windows Professional на домашней машине: предустановлена таки чаще Home, у которой возможность подключения к ней по rdp отключена.
                                                                  +1
                                                                  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.
                                                                    0
                                                                    с новыми версиями win10 нет:(
                                                                      0
                                                                      С насколько новыми? На 1803 работает точно, прямо сейчас проверил. Зашел на github проекта, есть у кого-то на 1809 не работает и чинится правкой ini, ссылки есть в issue. Думаю, поднимется тоже.
                                                                        0
                                                                        Работает.
                                                                    0
                                                                    В общем, для многих вариант поставить TV на машину будет более работающим и логичным. Тем более если тебе нужно, именно что, зайти на машину, включить Бетховена, и проведать свою майнинг-ферму. Собственно, даже TV стоит недорого, не говоря, что есть (для личного пользования) и некоторое кол-во других решений.

                                                                    Я не ратую за замену ssh на tv, я про прямое решение задачи. Хочешь поуправлять компом — настрой управление компом, а не страдай с VPS-кой!
                                                                      0
                                                                      Teamviewer гонит весь трафик через свои сервера. Я бы не стал его использовать для доступа к своему компьютеру на постоянной основе именно в плане безопасности. Опять же насчёт статьи: насколько я понял, она про ssh и про то, что его можно использовать не только по прямому назначению. А доступ с компа на комп через VPS приведён в качестве примера такого использования.
                                                                        0
                                                                        «даже TV стоит недорого» — 2000 в месяц?
                                                                        Ну и в целом пока что купить белый IP — это 200р. в месяц, что позволяет и без извратов с VPS делать. А для извратов можно и за 1 EUR взять сервер с белым IP в Европе.
                                                                          0
                                                                          дешевле VPS за 55р/месяц, а через него уже что угодно настраивай, ssh+vnc например
                                                                            0
                                                                            А вы на что отвечали: на фразу «Я не ратую за замену ssh на tv, я про прямое решение задачи»?
                                                                            P.S. И, конечно, vnc — никак не замена tv. Ну вот как ни крутите. Я про набор фич и качество картинки… Но, конечно, по соотношению «цена/качество» tv проиграет любому бесплатному продукту, тут тоже не о чем спорить.
                                                                          +1
                                                                          В обратном режиме слушающий TCP-порт открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента. Пригождается такое редко, но, как правило, очень метко.


                                                                          На самом деле, пригождается такое очень часто, когда вам нужно сделать себе нормальный RDP-доступ к машине, которая расположена в какой-нибудь корпоративной сети с драконовскими политиками удаленного подключения.

                                                                          На машине запускается ssh-клиент (+ cntlm, если корпоративная прокся не разрешает basic) и на ssh-сервер публикуется localhost:3389 от машины (не забудьте только разрешить в настройках ssh-сервера ssh-клиентам указывать на каком интерфейсе публиковать, иначе порт опубликуется на всех). Кстати, putty и kitty для этого сценария не подходят — у них есть странный глюк, что rdp-подключение пройдет, но тут же отвалится. А вот bitvise ssh client исполняет такое без проблем.
                                                                          0
                                                                          Ну вы конечно и придумали. А я просто настроил DDNS бесплатный и перебросил порт на комп.
                                                                            0
                                                                            Всё классно, единственный нюанс — открытость этого порта не только для вас, но и для любого пользователя из интернета. При наличии уязвимости в сервере RDP — ваш компьютер уже не совсем ваш.

                                                                            В предложеной экзотической схеме для получения доступа к вашему компьютеру требуется уже две уязвимости — одна в сервере SSH, другая в сервере RDP.

                                                                            Ну и не всегда сейчас провайдер даёт конечному оборудованию глобальный IP-адрес, пусть и динамический.
                                                                              0
                                                                              а всегда ли DDNS пробивается через провайдерский nat?
                                                                                +2
                                                                                А dyndns через NAT провайдера и не пробьёт. Это решение для тех провайдеров, которые дают белый IP, но динамически.
                                                                              0
                                                                              Я конечно могу сильно ошибаться, но в данном варианте использования не проще было «завести» Hamachi на дескотопе и просто добавить необходимые устройства в сеть. Да, в бесплатной версии там есть ограничения, но много кому в данном сценарии использования необходимо больше машин? По поводу запуска стороннего приложения на каждой из машин участников сети, не расцениваю это как большой минус.
                                                                                0
                                                                                А если «на каждой из заранее неизвестного множества машин» (упомянутый выше в комментах случай «зайти от друга»)?
                                                                                  0
                                                                                  Как минимум для «зайти от друга» вам необходимо будет иметь в наличии ваш RSA ключ и иметь " в голове" адресс связующего сервера. Что мешает иметь на флешке клиент hamachi?

                                                                                  Да и сорить секретными ключами на «неизвестном множестве» не хочется. а если начинать автоматизировать дело по их контролю, то тут мне кажется мы выходим за рамки «простого способа»
                                                                                +1
                                                                                Я для решения этой задачи использую ZeroTier. Не нужны внешние сервера, все устройства получаются в одной локалке, где бы они не находились.
                                                                                  –2
                                                                                  Какая ненавязчивая реклама я.
                                                                                    0
                                                                                    Извините чайника, но бесплатные лимиты AWS тоже позволят развернуть такую инфраструктуру?
                                                                                      0

                                                                                      Один t2.micro-инстанс можно вертеть бесплатно, вроде бы позволят

                                                                                      0
                                                                                      Сначала порадовался тому, что и яндекс стал давать облачные сервера в аренду, а потом посмотрел на цену и понял, почему я об этом до сих пор не знал. Облачный сервер с такими параметрами реально купить в 8-10 раз дешевле в очень многих местах. Смысл предложения яндекса не очень понятен, цена похожа на заградительную.
                                                                                        0
                                                                                        Потому что нужно сравнивать услуги одного класса. Условно — какой-нибудь хостинг типа Hetzner/timeweb/flops вообще не про то же самое, что и Яндекс. Одно — тупые VDS на непонятном оборудовании, второе — виртуальная инфраструктура с широким спектром доп. услуг. Понятно, что они могут быть не нужны, поэтому первые и выживают.
                                                                                        0
                                                                                        Попробовал описанное в статье. Как-то очень ненадежно получается.
                                                                                        дома 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. ЧЯДНТ?
                                                                                          +1
                                                                                          Может быть какой-то из роутеров по пути от вас до SSH-сервера имеет короткий срок жизни TCP-сессий в своей таблице NAT. По умолчанию SSH-сервер настроен так, чтобы не посылать никаких лишних пакетов. Иными словами, если клиент подключился, и ничего не делает, а серверу нечего ему сказать, то никаких данных по TCP-подключению не передаётся. Домашний роутер запросто может быть настроен так, чтобы забывать TCP-подключения после, к примеру, 10 минут простоя. Может получиться так, что TCP-сессия reverse port forwarding-стороны уже давным давно забыта на роутере, но SSH-клиент и SSH-сервер по-прежнему считают что между ними установлено TCP-подключение.

                                                                                          Это можно решить установкой параметров ServerAliveInterval на SSH-сервере и ClientAliveInterval на SSH-клиенте. Если установить их оба в, к примеру, 300, то каждые 5 минут будет происходить обмен Keep-Alive сообщениями, что, в свою очередь, будет убеждать все промежуточные роутеры в том, что сессия жива. Кроме того, даже если какой-то из этих роутеров по какой-то причине сбросит сессию, клиент и сервер будут способны относительно быстро этот факт обнаружить и установить подключение повторно.
                                                                                            0
                                                                                            Кажется, помогло. Хотя поддержанием соединения и переподключением у меня должен был заниматься специально обученный autossh. Похоже, надо писать свой.

                                                                                        Only users with full accounts can post comments. Log in, please.