Есть очень много способов управлять удаленного рабочего стола Linux компьютера — VNC, RDP и т.д. Я затрону самой базовой способ — CLI (командная строка).

Часть первая уже была на хабре здесь как один из советов. С этого и начнем — это довольно простой способ для запуска приложения с удаленного компьютера на локальный экран. Это может быть полезно как быстрое решение для преодоления местных ограничений которых нет на удаленной машине (сетевые или аппаратные ограничения, запуск приложения которого нет на локального компьютера). Необходимо иметь X сервер работающий на локальной машине и по крайней мере одно рабочее окно терминала. С терминала (GNOME-Terminal, Konsole, Xterm) делаем

Не всегда есть возможность, да и не всегда надо, строить полноценный туннель с интерфейсной парой адресов. Иногда нам нужно лишь «прокинуть» вполне определённые порты.

Тут важно понимать, что туннель можно организовать как изнутри сети, к ресурсам которой вы хотите получить доступ, на внешний ssh-сервер. Также можно организовать туннель с хоста в Интернете на пограничный ssh-сервер сети, чтобы получить доступ к внутренним ресурсам.

Доброго времени суток. Попробуем дополнить и расширить статью SSH-туннели — пробрасываем порт. Рассмотренными примерами мы убьем сразу 2 задачи:
1. Межсетевая коммуникация через промежуточный сервер, когда между сетями пути нет.
2. Создание безопасного соединения через не доверенную сеть.

Каждый пользователь Интернета хотя бы раз задумывался об анонимности в Сети. В этой заметке я расскажу об одном из самых простых способов настройки собственного прокси-сервера, который надежно скроет ваш IP-адрес и зашифрует передаваемую информацию.

Иногда во время тестирования веб-приложений может понадобится доступ к ним снаружи (то есть из публичного Интернета). Например некоторые API используют коллбеки.

В таком случае можно создать обратный SSH-туннель чтоб расшарить свой локальный сервер. Но для этого нужен доступ к публично доступной машине с SSH и нужными портами открытыми на фаерволе.

Но не всегда найдется такая машина, и влом покупать VPS или что-то в этом роде. В таком случае localtunnel — как раз то что надо.

localtunnel — инструмент специально предназначеный для того чтоб временно расшарить локальный веб-сервер в Интернете. Он работает как клиент к публичному сервису обратного туннелирования с открытыми исходниками.

Использовать его очень просто:

localtunnel 8080

Эта команда сделает локальный сервис на порту 8080 доступным на порту 80 на домене который выведет утилита.

Конечно перед использованием все-таки надо устанавить и настроить программу.
Установка для всех пользователей:

sudo gem install localtunnel

После этого при первом запуске нужно указать свой публичный ключ для аутентификации:

localtunnel -k ~/.ssh/id_rsa.pub 8080

Если у вас нет готовых ключей для SSH, их можно сгенерировать такой командой:

ssh-keygen -t rsa

Больше информации (на английском) и исходники – на Гитхабе.

UPD: Вышенаписанное справедливо для Unix-систем. В Windows наверное может работать через Cygwin.

Взял Google Chrome portable и столкнулся с необходимостью завернуть траффик в ssh-туннель.
Да так, чтобы никто об этом не узнал… ну, кроме гугла, конечно.
Однако, как заставить портабл-хромого ходить через прокси под корпоративной запиленной виндой?

Disclaimer
Этот пост появился здесь по нескольким причинам:
1) Меня попросил сам Boomburum
2) Есть предположение, что на хабре всё-таки есть люди, имеющие прямое отношение к IT, но при этом имеющие весьма отдалённое представление о пользе SSH и её извлечении из обычного домашнего роутера, и которым, надеюсь, будет весьма интересно и полезно об этом узнать.

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:
А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.
Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.
Специально для GrammarNazi:
Пишите пожалуйста об ошибках в личку — обещаю исправиться.

Бла-бла-бла, а топик-то о чём?
Итак, я обещал рассказать «как поднять ssh-туннель домой без необходимости оставлять включённым домашний ПК» и, как правильно догадался peter23 речь пойдёт про ssh-сервер на роутере.

Доброго времени суток, Хабр.

Не нашел здесь топиков на данную тему, поэтому я решил написать пошаговое руководство.

Итак, для начала разберемся с тем что использовалось.

Первое — это роутер на dd-wrt.
И второе — смартфон на андроиде с ssh и samba клиентами. Я использовал ConnectBot и AndSMB.

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

Фактически это описание бэкдора, поэтому убедитесь, что вы не нанесете вреда чужой сети и что локальные администраторы в курсе ваших манипуляций.

Задача: разместить линуксовый компьютер в сети за NATом, и иметь к нему доступ из внешнего мира. Например, вы траблшутите или поддерживаете что-то у клиента, и чтобы не сидеть у него в офисе, нужно быстро соорудить удаленный доступ. Или, например в 3G-сетях клиенты как правило получают приватные адреса, а нам нужен доступ к компьютеру, где другой связи нет.

Данный вольный перевод был мотивирован необходимостью в собственном понимании сабжа после прочтения ряда постов, начало которым было положено здесь, спасибо хабраюзеру levinkv

Использование ssh socks прокси совместно с MSF Reverse TCP Payloads

Иногда пентестерам необходимо перенаправлять свой сетевой трафик через различные прокси для получения доступа к частным сетям, для обхода межсетевых экранов, или же для сокрытия своих следов. Для решения таких задач специалисты имеют целый арсенал возможностей разнородного туннелирования и переадресации трафика, чтобы работать в различных сетевых архитектурах при тестировании. Каждый случай подобной работы определенно зависит от служб, запущенных на прокси-сервере и уровню доступа к этим службам.

Один из моих любимых случаев (как и многие другие) это работа с OpenSSH Socks прокси. Удаленный ssh прокси дает возможность различными способами переадресовывать трафик через ssh туннель. Тем не менее существует главный недостаток в случае с socks прокси — вы «не можете» использовать сушествующие reverse tcp payloads, которые поставляются с Metasploit framework (и многими другими подобными инструментами). Однако, это не совсем так. Есть возможность для включения некоторых функций OpenSSH в целях обхода ограничений при использовании ssh перенаправления.

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

Введение:
Кто бы что ни говорил, но ледовая обстановка в отечественном сегменте становится все более тяжелой. За нас взялись всерьез, обкладывают флажками, взрывают ровные тропинки натоптанные по бескрайним ледяным полям, вспарывают ледоколами привычные пути доставки провианта и под предлогом борьбы с браконьерами, расставляют капканы за каждым вторым торосом. Все идет к тому что проход с одной льдины на другую скоро будет происходить только через КПП с автоматчиками, по предварительной заявке в письменном виде и после предъявления паспорта и мандата из рыбнадзора. И только непослушнозаконные браконьеры будут посмеиваться в лисьи воротники над жалкими попытками геологических партий с большой земли испортить им жизнь.

Что делает ssh -R © erik, unix.stackexchange.com

Подключиться к сервису за NAT, имея человека рядом с сервисом, вооруженного ssh, и белый ip у себя.

Опция -R

В ssh есть режим, в котором он открывает порт на сервере и, через туннель от сервера до клиента, перенаправляет соединения в указанный адрес в сети клиента.

То есть нам нужно поднять sshd, попросить человека выполнить

$ ssh -N -R server_port:target:target_port sshd_server

И у нас на машине с sshd откроется порт server_port, который будет туннелироваться в target:target_port в сети этого человека.

Как в sshd_config ограничить права

Всем известно, что с помощью ssh можно делать перенаправление портов (создавать туннели). Еще из мануала по ssh вы могли узнать, что OpenSSH умеет динамически открывать порты для удаленного перенаправления и выполнять строго определенные команды. Также всем известно, что для Ansible (не считая Tower) нет такого понятия как сервер и клиент (в смысле ansible-server/ansible-agent) — есть сценарий (playbook) который можно выполнить как локально, так и удаленно через ssh-соединение. Еще есть Ansible-pull, это скрипт который проверяет git-репозиторий с вашими плейбуками и при наличии изменений запускает плейбук для применения обновлений. Там где нельзя пушить в большинстве случаев можно использовать pull, но бывают исключения.

В статье я попробую рассказать о том как можно использовать динамическое выделение портов для ssh-туннелей в реализации подобия функции provisioning-callback для бедных на любом сервере с OpenSSH и Ansible, и как я до этого дошел.

Ansible — прекрасное средство управления серверами. Совместно с git он позволяет перейти в парадигму deploy as code со всеми вытекающими отсюда прелестями, такими как ревью кода, мердж (пулл) реквесты изменений и тому подобное. Особенно это актуально если над этим работает команда, а не единственный человек.

В этом свете становится очевидно удобным хранить настройки подключения к управляемым хостам прямо в этом же репозитории, помимо файла inventory/hosts (его вообще лучше вынести в какой-нибудь сервис вроде CMDBuild или похожие). То есть, если на хосте поменялся скажем порт подключения или IP адрес, остальные члены команды должны это получить при следующем подтягивании изменений из репозитория, а не вносили каждый изменения в свой файл ~/.ssh/config.

Причём большинство параметров будут работать должным образом без каких-то усилий, но не всё так просто если вы хотите использовать ssh-туннели.

В преддверии Нового Года хотелось бы поделиться с сообществом Хабрахабр простым розыгрышем, который случайно пришёл в голову при работе с SSH-туннелями.

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

Наверняка многие системные администраторы сталкивались с ситуацией когда количество удалённых пользователей в компании становилось больше одного столько, что мысли о нормальном VPN вместо nat-а на скорую руку не давали покоя и становились навязчивой идеей. И уверен каждый морщился, когда понимал, что предстоит объяснять пользователям, что и где нажимать. А в моём, персональном случае ещё и позиция в отношении подопечных: «они не должны даже задумываться как это работает».

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

Оглавление:

1) Local TCP forwarding
2) Remote TCP forwarding
3) TCP forwarding chain через несколько узлов
4) TCP forwarding ssh-соединения
5) SSH VPN Tunnel
6) Коротко о беспарольном доступе
7) Спасибо (ссылки)