По данным ssh.com и Википедии, первая версия и реализация протокола SSH была выпущена в 1995 году.
Задача автора заключалась в разработке безопасной альтернативы rlogin, telnet и rsh, которые затем использовались для удаленного администрирования.
Любопытно, что появлению протокола SSH способствовал инцидент информационной безопасности, в результате которого злоумышленник собрал внушительную базу логинов/паролей с серверов, просто прослушав университетскую сеть и выделив пакеты аутентификации (логин/пароль).
пары передавались в незашифрованном виде).
Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизирован IETF в 2006 году.
С тех пор он стал стандартом де-факто для удаленного управления системами с помощью текстовой консоли.
Помимо самой текстовой консоли, протокол предоставляет массу других полезных функций, таких как передача файлов и переадресация портов.
Именно о пробросе портов и его не совсем очевидном применении пойдет речь в этой статье.
Протокол SSH обеспечивает два режима переадресации портов — прямой и обратный.
Прямой режим позволяет вам открыть порт прослушивания TCP на стороне SSH-клиента и перенаправлять все соединения к этому порту на сторону сервера.
Например, если на нашем SSH-сервере работает сервер удаленного рабочего стола (RDS), мы можем использовать протокол SSH для подключения к этому серверу, даже если прямое сетевое подключение невозможно (например, заблокировано брандмауэром).
Так: 
Второй режим проброса портов — обратный — позволяет поменять роли SSH-сервера и клиента (по отношению к пробрасываемому порту).
В обратном режиме порт прослушивания TCP открывается на стороне SSH-сервера, а приложение, обслуживающее этот порт, находится на стороне SSH-клиента.
Это редко бывает полезно, но, как правило, очень точно.
Объединив эти два режима и наш пример с сервером удаленных рабочих столов, можно получить следующую конфигурацию: 
На первый взгляд это выглядит лишним.
Но наряду с кажущейся избыточностью мы получили два важных свойства:
- Единственное, что требуется от сети для корректной работы этой схемы — это обеспечить постоянство сетевого адреса узла, на котором расположен SSH-сервер.
Узлы, на которых работает RDS-сервер и клиент, могут менять свои сетевые адреса хоть каждую минуту (а могут даже иметь адреса в частной сети; нам нужен только исходящий NAT, что часто и подразумевается под формулировкой «подключение к Интернету»).
).
- Несмотря на то, что RDS-сервер доступен нам из любой точки Интернета, другие пользователи не могут установить к нему соединение (при условии отсутствия уязвимостей в SSH-сервере).
А поскольку протокол RDS имеет свой собственный контроль доступа, то даже в случае успешной атаки на SSH-сервер злоумышленнику необходимо будет провести атаку и на RDS. Вероятность наличия как уязвимости в SSH-сервере, так и уязвимости в RDS-сервере гораздо меньше, чем для каждого компонента в отдельности.
Один — транспортный — позволяет устанавливать SSH-соединения.
Другой – внутренний – используется в прикладных целях.
Из этого наблюдения в последующих статьях мы постараемся сделать несколько интересных выводов, а пока вернемся к нашим экспериментам.
Подключитесь к домашнему компьютеру
На дворе XXI век, доставка сетевого пакета из Сибири в Калифорнию занимает 0,1 секунды, весь мир опутан компьютерными сетями, а TCP/IP есть даже в зубных щетках.Казалось бы, при такой связи всего и вся мы уже давно должны были иметь возможность управлять компьютером не только посредством физического присутствия рядом с устройствами ввода, но и удаленно, по сети.
Тем более, что для этого существует масса технологий и протоколов.
Удаленный рабочий стол от Microsoft, вариации на тему VNC в *nix-системах, решения от Citrix, их тысячи.
Тем не менее, мало кто из нас может похвастаться возможностью подключиться к домашнему компьютеру из любой точки мира с помощью любого из этих технологии.
Есть две причины, по которым мало кто может похвастаться подключением к собственному домашнему компьютеру, и они связаны друг с другом.
Первая из них – отсутствие адреса в глобальной сети у типичного домашнего компьютера.
Корни такого положения дел уходят в 1981 год, в котором впервые был описан стандарт IPv4, который до сих пор используется (конечно, с изменениями и дополнениями) для адресации большинства узлов в Интернете.
Авторы стандарта решили, что адресного пространства емкостью 3,7 миллиарда адресов будет достаточно для всех устройств в мире, но реальность оказалась суровой.
Ожидается, что к сентябрю 2019 года в Интернете IPv4 не останется свободных адресов.
Кроме того, типичный пользователь Интернета, не имеющий веб-сайтов, может легко пользоваться всеми благами цивилизации, не имея адреса в глобальной сети, ограничиваясь вместо этого только адресом в частной сети и провайдерским NAT. Другими словами, для большинства пользователей Интернета нет разницы между наличием и отсутствием глобального IP-адреса у их оборудования.
В таких условиях количество тех, кому провайдер выдает глобальный IP-адрес в глобальной сети, стремительно сокращается.
В результате типичный домашний компьютер находится в частной сети и не имеет глобального адреса.
Даже в том случае, когда провайдер все-таки присваивает оборудованию пользователя адрес в глобальной сети, это оборудование представляет собой домашний маршрутизатор, выполняющий NAT из домашней частной сети.
Пользователь, конечно, может «пробросить порт» на роутере, но даже в этом лучшем случае глобальный адрес роутера может меняться изо дня в день.
Да, есть провайдеры, которые за скромную плату предоставляют услугу «Статический IP», но на практике где-то в этот момент пользователь понимает, что игра не стоит выделки, и если нужно что-то сделать с домашним компьютером, тогда вы можете сделать это по телефону.
Самые упорные смогут пройти этот квест до конца и столкнуться со второй причиной, почему открытие доступа к своему компьютеру через Интернет – развлечение только для сильных духом.
Причина банальна – информационная безопасность.
Глобальная сеть глобальна, потому что рано или поздно к вам в ворота постучатся с другого конца света и с недобрыми намерениями.
Найти открытый порт, на который отвечает сервер удаленных рабочих столов, не очень сложная задача, и будьте уверены, рано или поздно на ваш сверхсекретный порт 32167 придет TCP SYN из китайской деревни.
Возвращаясь к нашей экзотической переадресации портов с помощью SSH, вы можете видеть, что ее возможности устраняют обе эти причины.
Приобретите себе TeamViewer
Сразу стоит отметить, что TeamViewer — это большой продукт с огромным количеством самых разных возможностей.В этой статье мы лишь соберем способ безопасного подключения через Интернет по протоколу удаленного рабочего стола к компьютеру, расположенному за NAT. Однако я бы рискнул предположить, что подключение к любому компьютеру, имеющему доступ в Интернет, является главной отличительной особенностью TeamViewer, благодаря которой этот продукт так популярен.
И именно такое соединение мы можем реализовать своими руками, используя нашу SSH-конфигурацию из первой части статьи.
Итак, условия задачи: у вас есть домашний компьютер и ноутбук, оба под управлением Windows 10. Вам необходимо убедиться, что с ноутбука вы можете получить доступ к домашнему компьютеру по протоколу удаленного рабочего стола из любой точки мира.
Наша система будет включать домашний компьютер-сервер удаленного рабочего стола, ноутбук с клиентом удаленного рабочего стола и 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:)
Теперь давайте запустим наш SSH-сервер.copy $HOME/.ssh/id_rsa f:\
Создадим виртуальную машину (ВМ) в Яндекс.
Облаке.
Для наших целей вы можете выбрать «легкую» ВМ с 1 vCPU и 0,5 гигабайта оперативной памяти.
В разделе настроек сети выберите сеть по умолчанию с автоматическим IP-адресом.
В разделе «доступ» в качестве логина введите «home»; в поле ввода SSH-ключа скопируйте то, что отображалось в нашей консоли на предыдущем шаге:
Нажмите «Создать виртуальную машину» и дождитесь завершения.
После того, как создание виртуальной машины будет завершено, нам нужно будет узнать ее IP-адрес: 
Нам понадобится IP-адрес нашей виртуальной машины для запуска SSH-клиента на домашнем компьютере и ноутбуке.
Запустим его на компьютере вот так (в этой и следующих командах нужно заменить 84.201.141.36 на IP-адрес вашей ВМ): ssh -NR 3389:localhost:3389 [email protected]
На вопрос о подключении к неизвестному серверу ответьте «да».
Если после этого мы не увидим никакого текста на консоли, значит, все прошло нормально.
Теперь настроим ноутбук.
Скопируем приватный ключ с нашей флешки: mkdir -Force $HOME/.
ssh copy f:\id_rsa $HOME/.
ssh/id_rsa
И давайте запустим SSH-клиент: ssh -NL 1025:localhost:3389 [email protected]
Теперь вы можете запустить клиент удаленного доступа к рабочему столу (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
Теперь давайте создадим настоящий скрипт. Откроем наш любимый текстовый редактор (подойдет и Блокнот) и напишем следующий скрипт (не забывая заменить 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 [email protected]
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 [email protected]
Start-Sleep -Seconds 15
}
Наконец, мы зарегистрируем его для запуска при запуске, используя «gpedit.msc».
Перезагружаем компьютер и ноутбук (чтобы убедиться, что все запускается корректно) и вуаля! Теперь наш домашний компьютер и наш ноутбук навсегда связаны друг с другом (пока наша виртуальная машина в Яндекс.
Облаке включена и доступна).
Хорошо?
Ну, разве это не здорово? В любом кафе, в любом аэропорту можно подключиться к дому и посмотреть любимые картинки с котиками.Или порадуйте свою семью, сыграв на полную громкость 5-ю симфонию Бетховена.
Или спросите об успехе вашей майнинг-фермы.
Или посмотрите, что происходит дома, с помощью веб-камеры.
Сколько применений имеет эта способность «телепортироваться»? Но у нашего решения есть и недостатки.
Во-первых, настройка соединения – не самый простой и приятный процесс.
А если что-то пойдет не так, отладка даже немного сложнее, чем первоначальная настройка.
Конечно, эту проблему можно решить, проявив упорство и терпение, но даже тот небольшой объем труда, который необходимо затратить, может вызвать сомнение в целесообразности затраченных усилий.
Во-вторых, виртуальная машина в облаке стоит денег.
В случае с Яндексом минимум, на который можно рассчитывать, — 480 рублей в месяц.
Это, конечно, не заоблачные деньги, но все же свои, заработанные в поте лица.
Стоит ли просмотр картинок с котами своих денег, каждый решает сам, но вполне может быть, что все преимущества нашего решения будут перечеркнуты его ценой.
Вопрос цены можно существенно сгладить, разделив расходы с друзьями и единомышленниками.
Поскольку виртуальная машина используется для задач, не требующих заметных вычислительных мощностей, снижение производительности крайне маловероятно.
Да и экономический эффект заметен: если десять человек арендуют виртуальную машину, то всем придется платить всего по 48 рублей в месяц.
Правда, в этом случае гармонию может нарушить вопрос доверия: любой из единомышленников имеет возможность подключиться к другому компьютеру через SSH-сервер.
Если у всех есть надежные пароли на своих учетных записях, это не проблема.
Но, давайте посмотрим правде в глаза, надежный пароль для входа в домашний компьютер – это скорее исключение, чем правило.
Продолжение следует
Итак, предположим, что мы собрали 10 единомышленников, все настроили, как описано выше, и у всех все работает. Наш клуб любителей картинок с котиками успешно пользуется возможностью выйти к себе домой через Интернет всего за 48 рублей в месяц без регистрации и СМС, все довольны и счастливы.Вопрос в следующем: ограничены ли возможности нашей «технологии» только кошками и нельзя ли ее использовать для чего-то более серьезного? Конечно, это возможно.
Если заменить в наших рассуждениях «домашний компьютер» на «построить сервер в облаке», а «ноутбук» на «рабочий компьютер в офисе», то получится нечто достойное названия «система доступа к инфраструктуре разработки».
А если вместо билд-сервера у нас будет IP-камера, а вместо рабочего компьютера пост охраны, мы получим «систему видеонаблюдения».
Однако в обоих случаях вам придется уделить больше внимания вопросам контроля доступа.
В частности, если вы используете SSH-сервер совместно с несколькими пользователями, вам необходимо изолировать этих пользователей друг от друга.
И при таком совместном использовании мы вынуждены назначать каждому ресурсу каждого пользователя свой отдельный TCP-порт и запоминать его номер.
Адресация по номеру вскоре может стать довольно утомительной, поэтому мне хотелось бы иметь возможность присваивать ресурсам осмысленные имена.
Но о том, как улучшить ситуацию, мы поговорим в следующей статье.
А пока спасибо за внимание и поделитесь своими мыслями в комментариях.
Теги: #Сетевые технологии #Сделай сам или Сделай сам #Windows #Администрирование сервера #vpn #cloud #PowerShell #ssh #удаленный рабочий стол
-
Teeworlds По-Новому
19 Oct, 24 -
Портативный Python — Все Ношу С Собой!
19 Oct, 24 -
Тв-Лампа?
19 Oct, 24
