Информационный пост на тему ssh и его возможностей по туннелированию трафика. С помощью ssh подключения можно совершать очень много простых, полезных и неочевидных вещей. Иногда это очень удобно. Я рассмотрю два примера, которые сам регулярно использую. Для их реализации вам необходим обычный ssh доступ к какому-то серверу в интернете.
SOCKS-прокси через ssh. Вы можете без проблем поднять у себя на компьютере локальный socks прокси с использованием удаленного сервера. Для этого локально подключитесь к серверу по ssh примерно таким образом:
Дальше идёте в любой браузер в настройки прокси и указываете там в параметрах для socks 5 свой локальный socks сервер: localhost, порт 3128. Дальше можете сразу же проверить, какой внешний ip адрес будет показывать ваш браузер. В общем случае это должен быть ip адрес сервера, к которому вы подключились по ssh.
Для подобного подключения подойдет современный windows terminal, который уже имеет встроенный ssh клиент. То есть подключиться проще простого и ничего особо настраивать не надо. На самом сервере, к примеру, можно быстро поднять adguard и использовать его как собственный блокировщик рекламы. При этом не придется замусоривать локальную машину для установки блокировщиков, которые точно не известно, что делают на вашем компе.
Можно завести отдельный браузер и использовать его только с прокси для фильтра рекламы или обхода блокировок. Тогда не придется постоянно менять настройки на основном. Применения для подобного прокси может быть много.
Переадресация портов через ssh. Это тоже очень простая и полезная история. С помощью ssh можно удаленный порт переадресовать себе локально.
В данном случай я удаленный порт 8080, который слушает только localhost (127.0.0.1) переадресовал себе локально на порт 8181. Тут важно не перепутать удаленную и локальную машины. 127.0.0.1:8080 - это удалённый сервер, к которому мы подключились по ssh, а 8181 локальный порт на машине, с которой происходит подключение к серверу.
С помощью этой переадресации можно локально получить доступ к порту, который закрыт для удаленных подключений. Обычно локальные mysql клиенты используют такие подключения. Но не обязательно. Можно банально какой-то веб сервер запустить на сервере, закрыв к нему доступ из интернета, а подключаться к нему со своего компа через ssh. Так можно закрывать какие-то панели управления от посторонних глаз.
#ssh #полезности
SOCKS-прокси через ssh. Вы можете без проблем поднять у себя на компьютере локальный socks прокси с использованием удаленного сервера. Для этого локально подключитесь к серверу по ssh примерно таким образом:
ssh -D 3128 root@95.145.142.226Дальше идёте в любой браузер в настройки прокси и указываете там в параметрах для socks 5 свой локальный socks сервер: localhost, порт 3128. Дальше можете сразу же проверить, какой внешний ip адрес будет показывать ваш браузер. В общем случае это должен быть ip адрес сервера, к которому вы подключились по ssh.
Для подобного подключения подойдет современный windows terminal, который уже имеет встроенный ssh клиент. То есть подключиться проще простого и ничего особо настраивать не надо. На самом сервере, к примеру, можно быстро поднять adguard и использовать его как собственный блокировщик рекламы. При этом не придется замусоривать локальную машину для установки блокировщиков, которые точно не известно, что делают на вашем компе.
Можно завести отдельный браузер и использовать его только с прокси для фильтра рекламы или обхода блокировок. Тогда не придется постоянно менять настройки на основном. Применения для подобного прокси может быть много.
Переадресация портов через ssh. Это тоже очень простая и полезная история. С помощью ssh можно удаленный порт переадресовать себе локально.
ssh -L 8181:127.0.0.1:8080 root@95.145.142.226В данном случай я удаленный порт 8080, который слушает только localhost (127.0.0.1) переадресовал себе локально на порт 8181. Тут важно не перепутать удаленную и локальную машины. 127.0.0.1:8080 - это удалённый сервер, к которому мы подключились по ssh, а 8181 локальный порт на машине, с которой происходит подключение к серверу.
С помощью этой переадресации можно локально получить доступ к порту, который закрыт для удаленных подключений. Обычно локальные mysql клиенты используют такие подключения. Но не обязательно. Можно банально какой-то веб сервер запустить на сервере, закрыв к нему доступ из интернета, а подключаться к нему со своего компа через ssh. Так можно закрывать какие-то панели управления от посторонних глаз.
#ssh #полезности
Ранее я уже рассказывал о полезных возможностях ssh. Речь была о SOCKS-прокси и переадресации портов через ssh. Сейчас расскажу о том, как настроить полноценный vpn туннель с помощью подключения по ssh.
Сразу отвечу на вопрос, зачем это вообще нужно, если есть куча других способов настроить vpn. Все дело в простоте и времени настройки. Обычно на сервере уже есть настроенный openssh сервер, так что ничего дополнительно устанавливать не надо. Берёте любой линукс сервер или виртуальную машину и организовываете через него vpn канал.
Для начала вам нужно включить параметр в конфиге /etc/ssh/sshd_config:
и перезапустить службу sshd.
Далее с клиента подключаетесь к серверу по ssh со следующими ключами:
w3:3 - имена tun интерфейсов, которые будут созданы на клиенте и сервере (в данном случае tun3). Обращаю внимание, что подобное подключение напрямую из Windows работать не будет. Я для этого подключаюсь через WSL.
После подобного ssh подключения, на сервере и клиенте поднимаются tun3 интерфейсы и фактически vpn канал уже создан. Дальше вам нужно вручную назначить им ip адреса и можно передавать информацию по зашифрованному vpn каналу поверх ssh подключения. Что-то вроде этого надо сделать:
Я взял подсеть 10.20.30.0 с маской 30, где всего 2 ip адреса и объединил клиента и сервера в рамках это подсети. Теперь можно пинговать по этим адресам друг друга с сервера или клиента.
Дальше есть разные варианты, как использовать это подключение. Если вы с клиента захотите увидеть локальную сеть за сервером, то на самом сервере нужно будет настроить ip_forward и nat для tun интерфейса, а на клиенте добавить маршрут в эту локалку через vpn канал. Всё точно так же, как и на других vpn туннелях.
Если тема заинтересовала без проблем нагуглите пошаговую инструкцию. Я просто дал информацию о том, что так можно сделать. Как-то объединял по быстрому два филиала через такой туннель. Автоматизировал всё через обычные bash скрипты. Один сервер стоял на базе какой-то готовой сборки с веб панелью управления. И всё это дремучей версии, непонятно кем и как настроенный. Я не захотел туда лазить, разбираться и что-то ставить дополнительно. Просто настроил vpn поверх ssh и закрыл вопрос.
#ssh #vpn
Сразу отвечу на вопрос, зачем это вообще нужно, если есть куча других способов настроить vpn. Все дело в простоте и времени настройки. Обычно на сервере уже есть настроенный openssh сервер, так что ничего дополнительно устанавливать не надо. Берёте любой линукс сервер или виртуальную машину и организовываете через него vpn канал.
Для начала вам нужно включить параметр в конфиге /etc/ssh/sshd_config:
PermitTunnel yesи перезапустить службу sshd.
Далее с клиента подключаетесь к серверу по ssh со следующими ключами:
ssh -p 22777 -w3:3 root@111.222.333.444w3:3 - имена tun интерфейсов, которые будут созданы на клиенте и сервере (в данном случае tun3). Обращаю внимание, что подобное подключение напрямую из Windows работать не будет. Я для этого подключаюсь через WSL.
После подобного ssh подключения, на сервере и клиенте поднимаются tun3 интерфейсы и фактически vpn канал уже создан. Дальше вам нужно вручную назначить им ip адреса и можно передавать информацию по зашифрованному vpn каналу поверх ssh подключения. Что-то вроде этого надо сделать:
server: ip a add 10.20.0.1/30 dev tun3server: ip link set dev tun3 upclient: ip a add 10.20.0.2/30 dev tun3client: ip link set dev tun3 upЯ взял подсеть 10.20.30.0 с маской 30, где всего 2 ip адреса и объединил клиента и сервера в рамках это подсети. Теперь можно пинговать по этим адресам друг друга с сервера или клиента.
Дальше есть разные варианты, как использовать это подключение. Если вы с клиента захотите увидеть локальную сеть за сервером, то на самом сервере нужно будет настроить ip_forward и nat для tun интерфейса, а на клиенте добавить маршрут в эту локалку через vpn канал. Всё точно так же, как и на других vpn туннелях.
Если тема заинтересовала без проблем нагуглите пошаговую инструкцию. Я просто дал информацию о том, что так можно сделать. Как-то объединял по быстрому два филиала через такой туннель. Автоматизировал всё через обычные bash скрипты. Один сервер стоял на базе какой-то готовой сборки с веб панелью управления. И всё это дремучей версии, непонятно кем и как настроенный. Я не захотел туда лазить, разбираться и что-то ставить дополнительно. Просто настроил vpn поверх ssh и закрыл вопрос.
#ssh #vpn
Есть небольшая утилита для организации vpn подключения через ssh - sshuttle. Она есть в стандартных репозиториях популярных дистрибутивов. В Centos живет в репозитории epel. Также присутствует в pip, так как написана на python.
https://github.com/sshuttle/sshuttle
https://sshuttle.readthedocs.io/en/stable/usage.html
Установка:
Её удобство в простоте и функциональности. VPN соединение организуется поверх SSH. Покажу на примерах:
Выражение 0/0 эквивалентно маске 0.0.0.0/0, то есть весь трафик отправляем в этот туннель. Будьте аккуратны, когда начнёте тестировать. Вас отключит от текущего ssh соединения. Можете сразу же проверить, через какой ip вы выходите в интернет:
Должны увидеть внешний ip ssh сервера, к которому подключились. С помощью sshuttle удобно подключаться к jump host и дальше на целевое устройство. Допустим, на какое-то устройство или сервер (ip - 2.2.2.2) можно подключиться только через конкретный сервер (ip - 3.3.3.3). Используем для подключения sshuttle.
После подобного подключения у вас будет создан маршрут к 2.2.2.2/32 через ssh сервер 3.3.3.3. Дальше можете со своей машины подключиться к 2.2.2.2.
Во время тестов я столкнулся с ошибкой: fatal: server died with error code 255. Подключение по ssh осуществлялось, а потом sshuttle падал. Решил вот так:
Если используется нестандартный ssh порт, то указать его следует так:
Для использования ключа при ssh подключении, добавьте следующие опции:
Если что-то пойдёт не так, включите подробное логировние через ключ -vvvv. Увидите, какие правила sshuttle добавляет в firewall и как прописывает маршруты. Там никакой магии, всё наглядно.
В Windows через WSL2 тоже работает, что весьма удобно. Данной заметки достаточно, чтобы начать пользоваться программой, так что смело добавляйте в закладки.
#vpn #ssh
https://github.com/sshuttle/sshuttle
https://sshuttle.readthedocs.io/en/stable/usage.html
Установка:
# dnf install sshuttle# apt install sshuttle# pip install sshuttleЕё удобство в простоте и функциональности. VPN соединение организуется поверх SSH. Покажу на примерах:
# sshuttle -r user@1.2.3.4 0/0Выражение 0/0 эквивалентно маске 0.0.0.0/0, то есть весь трафик отправляем в этот туннель. Будьте аккуратны, когда начнёте тестировать. Вас отключит от текущего ssh соединения. Можете сразу же проверить, через какой ip вы выходите в интернет:
# curl ifconfig.me/ipДолжны увидеть внешний ip ssh сервера, к которому подключились. С помощью sshuttle удобно подключаться к jump host и дальше на целевое устройство. Допустим, на какое-то устройство или сервер (ip - 2.2.2.2) можно подключиться только через конкретный сервер (ip - 3.3.3.3). Используем для подключения sshuttle.
# sshuttle -r user@3.3.3.3 2.2.2.2/32После подобного подключения у вас будет создан маршрут к 2.2.2.2/32 через ssh сервер 3.3.3.3. Дальше можете со своей машины подключиться к 2.2.2.2.
Во время тестов я столкнулся с ошибкой: fatal: server died with error code 255. Подключение по ssh осуществлялось, а потом sshuttle падал. Решил вот так:
# sshuttle -r user@1.2.3.4 -x 1.2.3.4 0/0Если используется нестандартный ssh порт, то указать его следует так:
# sshuttle -r user@1.2.3.4:22334 0/0Для использования ключа при ssh подключении, добавьте следующие опции:
# sshuttle -r user@1.2.3.4 0/0 --ssh-cmd "ssh -i ~/.ssh/id_rsa"Если что-то пойдёт не так, включите подробное логировние через ключ -vvvv. Увидите, какие правила sshuttle добавляет в firewall и как прописывает маршруты. Там никакой магии, всё наглядно.
В Windows через WSL2 тоже работает, что весьма удобно. Данной заметки достаточно, чтобы начать пользоваться программой, так что смело добавляйте в закладки.
#vpn #ssh
GitHub
GitHub - sshuttle/sshuttle: Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin.…
Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling. - sshuttle/sshuttle
Нередко возникает задача по логированию действий пользователя на сервере. Я нагуглил простое и эффективное решение - log-user-session. Проблема возникла одна - никакого описания, как это настраивается. Даже примера конфига нет в репозитории, хотя в описании упомянуто, что он может существовать.
Пришлось потратить некоторое время, пока не разобрался, как эта программа работает. Результат мне понравился, так что возьму на вооружение, чтобы знать, что разработчики и прочие люди делают в консоли.
Проверял всё на Debian 11. Устанавливаем:
Убеждаемся, что программа log-user-session появилась в /usr/local/bin/. Для проверки её можно запустить в консоли и посмотреть, начала ли она писать лог вашей сессии в /var/log/user-session.
Дальше я не понял, как заставить утилиту писать логи пользователя. Сначала подумал, что её надо поставить, вместо стандартной shell, но это так не работает. Потом чисто методом тыка решил поискать, как настроить принудительный запуск через sshd и нашёл там подходящий параметр. Надо в sshd_config добавить параметр:
Теперь у каждого пользователя будет запускаться оболочка через log-user-session. Если попытаться её закрыть, то пользователя отключит от ssh. У обычного пользователя нет доступа к логам, так что они скрыть свою деятельность не смогут. Может и есть лазейки, но я не разбирал подробно эту тему.
А вот root сможет посмотреть, изменить логи или удалить. Так что если нужно гарантированно логировать действия root, то логи нужно пересылать на какой-то другой сервер, куда нет доступа с этого.
Заметку имеет смысл сохранить, если есть потребность в таком функционале. Я вообще нигде не нашёл информации по настройке этой программы. Какие вы использовали решения для задачи логирования действий пользователей? По идее, тут наколхозить можно много всяких способов, но решение с log-user-session мне показалось самым простым и эффективным. Она даже вывод MC отображает. Я сначала не понял, когда вывел лог работы пользователя в консоль, что это за сессия MC приехала. Потом сообразил, посмотрев текстовым редактором лог файл.
#security #ssh #linux
Пришлось потратить некоторое время, пока не разобрался, как эта программа работает. Результат мне понравился, так что возьму на вооружение, чтобы знать, что разработчики и прочие люди делают в консоли.
Проверял всё на Debian 11. Устанавливаем:
# apt install autoconf gcc make git# git clone https://github.com/open-ch/log-user-session# cd open-ch/log-user-session# ./autogen.sh# ./configure# make# make installУбеждаемся, что программа log-user-session появилась в /usr/local/bin/. Для проверки её можно запустить в консоли и посмотреть, начала ли она писать лог вашей сессии в /var/log/user-session.
Дальше я не понял, как заставить утилиту писать логи пользователя. Сначала подумал, что её надо поставить, вместо стандартной shell, но это так не работает. Потом чисто методом тыка решил поискать, как настроить принудительный запуск через sshd и нашёл там подходящий параметр. Надо в sshd_config добавить параметр:
ForceCommand /usr/local/bin/log-user-sessionТеперь у каждого пользователя будет запускаться оболочка через log-user-session. Если попытаться её закрыть, то пользователя отключит от ssh. У обычного пользователя нет доступа к логам, так что они скрыть свою деятельность не смогут. Может и есть лазейки, но я не разбирал подробно эту тему.
А вот root сможет посмотреть, изменить логи или удалить. Так что если нужно гарантированно логировать действия root, то логи нужно пересылать на какой-то другой сервер, куда нет доступа с этого.
Заметку имеет смысл сохранить, если есть потребность в таком функционале. Я вообще нигде не нашёл информации по настройке этой программы. Какие вы использовали решения для задачи логирования действий пользователей? По идее, тут наколхозить можно много всяких способов, но решение с log-user-session мне показалось самым простым и эффективным. Она даже вывод MC отображает. Я сначала не понял, когда вывел лог работы пользователя в консоль, что это за сессия MC приехала. Потом сообразил, посмотрев текстовым редактором лог файл.
#security #ssh #linux
