Есть небольшая утилита для организации 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
Вчера рассказал, как с помощью log-user-session можно логировать все действия. Сегодня хочу затронуть ещё одну полезную тему - оповещение о логине по SSH. Я настраиваю это почти везде, где подразумевается не только моё подключение к серверам. Это сильно упрощает контроль за инфраструктурой. Если что-то сломалось и ты видишь, что накануне кто-то подключался к серверу, путь к решению лежит на поверхности. Надо сразу написать и спросить, что делали на сервере, а параллельно посмотреть лог действий пользователя.
Вариантов решения этой задачи может быть много. Есть настроен Zabbix Server, то я делаю через него. Для меня это самое простое. Надо добавить айтем с анализом лог файла авторизаций и сделать триггер, срабатывающий на определённые строки. Если мониторинг развёрнут, то достаточно добавить готовый шаблон и дать Zabbix Agent доступ на чтение соответствующего лога. Обычно это /var/log/auth.log или /var/log/secure. Пример подобного мониторинга можно посмотреть у меня в статье. Она довольно старая, а сам я использую другой шаблон, но идея такая же. Каждый уже сам может доработать под себя.
Если используется система сбора логов, то логично настроить анализ и оповещения через неё. Zabbix не очень приспособлен для работы с логами, но в случае отсутствия централизованной системы сбора, для данной задачи он подойдёт. Не надо только очень сильно его нагружать этими логами и хранить их долго. Они будут лежать в обычной SQL базе.
Если системы мониторинга или сборов логов нет, то можно обойтись возможностями самой ОС. Достаточно установить postfix, настроить отправку почты через какой-то почтовый сервис, чтобы письма не улетали в спам. Настройка легко гуглится, есть и у меня на сайте.
Затем добавляем пользователям в .bash_profile небольшой код. Набросал и проверил прямо сейчас, по ходу написания заметки:
if [ -n "$SSH_CLIENT" ]; then
EMAIL="SSH login to $(hostname)\n
\nDATE: $(date)\n
\nUSER: ${USER} from $(echo $SSH_CLIENT | awk '{print $1}')"
echo -e $EMAIL | mail -s "SSH login to ${USER}@$(hostname) from $(echo $SSH_CLIENT | awk '{print $1}')" userpochta@mail.ru
fi
Пример вывода скрипта в итогом письме можно посмотреть во вложении к посту. Теперь при каждом логине в систему будет срабатывать этот код и отправлять уведомление. Если надо добавить сразу всем пользователям этот код и убрать у всех, кроме root, возможность его изменить, добавьте в файл /etc/profile.
#linux #ssh #security
Вариантов решения этой задачи может быть много. Есть настроен Zabbix Server, то я делаю через него. Для меня это самое простое. Надо добавить айтем с анализом лог файла авторизаций и сделать триггер, срабатывающий на определённые строки. Если мониторинг развёрнут, то достаточно добавить готовый шаблон и дать Zabbix Agent доступ на чтение соответствующего лога. Обычно это /var/log/auth.log или /var/log/secure. Пример подобного мониторинга можно посмотреть у меня в статье. Она довольно старая, а сам я использую другой шаблон, но идея такая же. Каждый уже сам может доработать под себя.
Если используется система сбора логов, то логично настроить анализ и оповещения через неё. Zabbix не очень приспособлен для работы с логами, но в случае отсутствия централизованной системы сбора, для данной задачи он подойдёт. Не надо только очень сильно его нагружать этими логами и хранить их долго. Они будут лежать в обычной SQL базе.
Если системы мониторинга или сборов логов нет, то можно обойтись возможностями самой ОС. Достаточно установить postfix, настроить отправку почты через какой-то почтовый сервис, чтобы письма не улетали в спам. Настройка легко гуглится, есть и у меня на сайте.
Затем добавляем пользователям в .bash_profile небольшой код. Набросал и проверил прямо сейчас, по ходу написания заметки:
if [ -n "$SSH_CLIENT" ]; then
EMAIL="SSH login to $(hostname)\n
\nDATE: $(date)\n
\nUSER: ${USER} from $(echo $SSH_CLIENT | awk '{print $1}')"
echo -e $EMAIL | mail -s "SSH login to ${USER}@$(hostname) from $(echo $SSH_CLIENT | awk '{print $1}')" userpochta@mail.ru
fi
Пример вывода скрипта в итогом письме можно посмотреть во вложении к посту. Теперь при каждом логине в систему будет срабатывать этот код и отправлять уведомление. Если надо добавить сразу всем пользователям этот код и убрать у всех, кроме root, возможность его изменить, добавьте в файл /etc/profile.
#linux #ssh #security
Я как-то раз уже вскользь упоминал о возможности пробрасывать порты через SSH в рамках общей заметки о разных возможностях этого протокола. Сейчас хочу поподробнее остановиться на этом с конкретным примером.
Допустим, у вас есть какой-то веб сервис на удалённом сервере, с которым работаете только вы. Хотя это не обязательно, но для упрощения будем считать, что это так. Вам нужен доступ к этому сервису через интернет, но при этом вы не хотите открывать его через интернет без ограничений. Тогда у вас есть как минимум 2 очевидных решения:
1️⃣ Настроить ограничение на подключение по IP. Это сработает в том случае, если у вас существует список статичных IP адресов, с которых вы подключаетесь, а необходимости подключаться с адресов не из этого списка не возникнет. Тогда всё просто. Настраиваете Firewall и забываете о проблеме. Но для надёжности неплохо было бы настроить мониторинг правил фаревола, так как я неоднократно сталкивался с ситуациями, когда по различным причинам фаервол не работал или необходимые правила в нём не были активны.
2️⃣ Настраиваете VPN туннель и подключаетесь к сервису через него. Тут уже нет ограничений по адресам, но придётся настроить и поддерживать дополнительный сервис, плюс ставить клиента на рабочие машины, с которых будете подключаться.
Рассказываю про третий, наиболее простой вариант. Пробрасываете локальный порт сервиса с сервера к себе на локальную машину с помощью SSH. Данный протокол безопасен и его можно оставлять доступным из интернета, используя авторизацию по сертификатам или сложный пароль. Для надёжности можно прикрыть Fail2ban или чем-то подобным.
Подключаемся с локальной машины по SSH следующим образом:
◽ 8080 - локальный порт машины, с которой подключаемся
◽ 127.0.0.1:80 - порт, на котором работает веб сервер, не забудьте его запустить только на localhost, чтобы с других адресов он не был доступен
◽ -N -f - ключи для запуска соединения в фоновом режиме, в WSL оно останется активным даже после закрытия терминала
Теперь можно открыть интерфейс Zabbix через проброшенный порт со своего компьютера: http://127.0.0.1:8080/zabbix/
Не нужно настраивать ни VPN, ни Firewall. На сервере открыт только порт SSH, вы можете подключиться к веб интерфейсу из любого места, где есть возможность использовать SSH соединение.
Все популярные SSH клиенты позволяют настраивать проброс портов и сохранять параметры. Так что достаточно один раз настроить соединение и использовать его. Можно и других людей так же подключать. А создав для каждого из них отдельного пользователя можно получить простой аудит подключений на основе логов SSH.
Берите на вооружение, особенно те, кто не умеет, не хочет, ему не нужно учиться настраивать Firewall, а хочется по-быстрому настроить безопасный доступ к какому-то сервису. Программисты часто грешат тем, что на тестовых серверах вешают базу на внешний интерфейс, чтобы подключаться к ней напрямую. А потом забывают, отключить, поменять дефолтную учётку и т.д. Лично сталкивался с этим и не раз.
Когда соединение станет не нужно, через
#linux #ssh
Допустим, у вас есть какой-то веб сервис на удалённом сервере, с которым работаете только вы. Хотя это не обязательно, но для упрощения будем считать, что это так. Вам нужен доступ к этому сервису через интернет, но при этом вы не хотите открывать его через интернет без ограничений. Тогда у вас есть как минимум 2 очевидных решения:
1️⃣ Настроить ограничение на подключение по IP. Это сработает в том случае, если у вас существует список статичных IP адресов, с которых вы подключаетесь, а необходимости подключаться с адресов не из этого списка не возникнет. Тогда всё просто. Настраиваете Firewall и забываете о проблеме. Но для надёжности неплохо было бы настроить мониторинг правил фаревола, так как я неоднократно сталкивался с ситуациями, когда по различным причинам фаервол не работал или необходимые правила в нём не были активны.
2️⃣ Настраиваете VPN туннель и подключаетесь к сервису через него. Тут уже нет ограничений по адресам, но придётся настроить и поддерживать дополнительный сервис, плюс ставить клиента на рабочие машины, с которых будете подключаться.
Рассказываю про третий, наиболее простой вариант. Пробрасываете локальный порт сервиса с сервера к себе на локальную машину с помощью SSH. Данный протокол безопасен и его можно оставлять доступным из интернета, используя авторизацию по сертификатам или сложный пароль. Для надёжности можно прикрыть Fail2ban или чем-то подобным.
Подключаемся с локальной машины по SSH следующим образом:
# ssh -L 8080:127.0.0.1:80 -N -f user@remote.host◽ 8080 - локальный порт машины, с которой подключаемся
◽ 127.0.0.1:80 - порт, на котором работает веб сервер, не забудьте его запустить только на localhost, чтобы с других адресов он не был доступен
◽ -N -f - ключи для запуска соединения в фоновом режиме, в WSL оно останется активным даже после закрытия терминала
Теперь можно открыть интерфейс Zabbix через проброшенный порт со своего компьютера: http://127.0.0.1:8080/zabbix/
Не нужно настраивать ни VPN, ни Firewall. На сервере открыт только порт SSH, вы можете подключиться к веб интерфейсу из любого места, где есть возможность использовать SSH соединение.
Все популярные SSH клиенты позволяют настраивать проброс портов и сохранять параметры. Так что достаточно один раз настроить соединение и использовать его. Можно и других людей так же подключать. А создав для каждого из них отдельного пользователя можно получить простой аудит подключений на основе логов SSH.
Берите на вооружение, особенно те, кто не умеет, не хочет, ему не нужно учиться настраивать Firewall, а хочется по-быстрому настроить безопасный доступ к какому-то сервису. Программисты часто грешат тем, что на тестовых серверах вешают базу на внешний интерфейс, чтобы подключаться к ней напрямую. А потом забывают, отключить, поменять дефолтную учётку и т.д. Лично сталкивался с этим и не раз.
Когда соединение станет не нужно, через
px axf посмотрите его pid и прибьёте через kill. Подобных подключений можно много открыть на разные локальные порты с разных удалённых серверов. #linux #ssh
Делюсь с вами малоизвестной, но полезной и функциональной находкой. Речь пойдёт про систему централизованного хранения и управления ключами для подключения по SSH к хостам - ssham. Я настроил её и разобрался, как с ней работать. Несмотря на то, что про ssham нет ни одного упоминания в интернете, кроме репозитория программы, она достойна внимания.
Идея ssham следующая. Вы устанавливаете её на любой Linux хост. Потом с её помощью через веб интерфейс управляете настройками подключения к другим хостам.
Для этого вы заходите в веб интерфейс ssham, добавляете туда хосты, пользователей, генерируете ключи. Для всего этого поддерживаются группы. А потом связываете ключи с пользователями, создаёте правила, кому на какой хост можно подключаться с помощью того или иногда ключа. Когда всё настроите, запускаете синхронизацию и ssham сам разложит по хостам нужные сертификаты, для которых настроено разрешение на подключение. Ключи можно как добавлять, так и отзывать/удалять.
Вы получаете централизованную систему хранения и управления доступами для SSH ключей. Теперь рассказываю, как её запустить. Документация очень скудная, мне пришлось довольно долго во всём самому разбираться. Поставить можно как напрямую на сервере, так и запустить в Docker. Для простоты описания, запустим всё в Docker.
Копируем репозитоий:
Делаем копию файла с параметрами окружения:
Заходим в .env и комментируем строку:
Пока я этого не сделал, у меня не работала синхронизация ключей по хостам. Несколько часов потратил, пока разобрался.
Далее собираем и запускаем образы:
Устанавливаем в контейнер app зависимости:
Инициализируем БД и добавляем туда demo данные:
Дальше идём в веб интерфейс по ip адресу и логинимся под superadmin / superadmin.
Логика работы с ssham следующая. Создаём SSH Key groups, добавляем SSH key и помещаем его в эту группу. Далее создаём Host group, добавляем Host и помещаем его в эту группу. В завершении создаём Rule, где указываем, что созданная SSH Key group имеет доступ к Host group. Или не имеет. Доступ можно как разрешить, так и запретить.
После того, как всё сделали, в Settings смотрим Public key сервера. Его нужно один раз самостоятельно распространить на управляемые хосты, добавив в ./ssh/authorized_keys. После этого идём в консоль сервера, где запущены контейнеры и выполняем синхронизацию:
После этого на управляемых хостах ключи будут добавлены в authorized_keys. Теперь можно забрать приватные ключи из веб интерфейса и раздать пользователям.
⇨ Исходники
#ssh #devops #управление
Идея ssham следующая. Вы устанавливаете её на любой Linux хост. Потом с её помощью через веб интерфейс управляете настройками подключения к другим хостам.
Для этого вы заходите в веб интерфейс ssham, добавляете туда хосты, пользователей, генерируете ключи. Для всего этого поддерживаются группы. А потом связываете ключи с пользователями, создаёте правила, кому на какой хост можно подключаться с помощью того или иногда ключа. Когда всё настроите, запускаете синхронизацию и ssham сам разложит по хостам нужные сертификаты, для которых настроено разрешение на подключение. Ключи можно как добавлять, так и отзывать/удалять.
Вы получаете централизованную систему хранения и управления доступами для SSH ключей. Теперь рассказываю, как её запустить. Документация очень скудная, мне пришлось довольно долго во всём самому разбираться. Поставить можно как напрямую на сервере, так и запустить в Docker. Для простоты описания, запустим всё в Docker.
Копируем репозитоий:
# git clone https://github.com/pacoorozco/ssham.git ssham# cd sshamДелаем копию файла с параметрами окружения:
# cp .env.example .envЗаходим в .env и комментируем строку:
#QUEUE_CONNECTION=databaseПока я этого не сделал, у меня не работала синхронизация ключей по хостам. Несколько часов потратил, пока разобрался.
Далее собираем и запускаем образы:
# export DOCKER_SSHAM_UID="$(id -u)"# docker-compose build# docker-compose up -dУстанавливаем в контейнер app зависимости:
# docker-compose exec app composer installИнициализируем БД и добавляем туда demo данные:
# docker-compose exec app php artisan key:generate # docker-compose exec app php artisan migrate:fresh --seedДальше идём в веб интерфейс по ip адресу и логинимся под superadmin / superadmin.
Логика работы с ssham следующая. Создаём SSH Key groups, добавляем SSH key и помещаем его в эту группу. Далее создаём Host group, добавляем Host и помещаем его в эту группу. В завершении создаём Rule, где указываем, что созданная SSH Key group имеет доступ к Host group. Или не имеет. Доступ можно как разрешить, так и запретить.
После того, как всё сделали, в Settings смотрим Public key сервера. Его нужно один раз самостоятельно распространить на управляемые хосты, добавив в ./ssh/authorized_keys. После этого идём в консоль сервера, где запущены контейнеры и выполняем синхронизацию:
# docker-compose exec app php artisan ssham:sendПосле этого на управляемых хостах ключи будут добавлены в authorized_keys. Теперь можно забрать приватные ключи из веб интерфейса и раздать пользователям.
⇨ Исходники
#ssh #devops #управление
Не зря существует поговорка: "Век живи - век учись". Буквально на днях узнал, что есть очень простой способ, как ограничить выполнение каких-то команд при подключении по SSH с аутентификацией через сертификат.
В файл authorized_keys перед самим сертификатом добавляем разрешённую команду:
И больше ничего не надо делать. Подключившийся, кроме top, ничего запустить не сможет. Команда top запустится автоматически при успешном подключении. Я просто пример привёл, как быстро протестировать возможность.
На практике это очень пригодится для служебных учётных записей, которые ходят по серверам и выполняют какие-то заскриптованные действия. Например, делают дамбы баз, запускают скрипты бэкапа и т.д. Достаточно просто добавить ограничение в виде command и учётная запись не сможет сделать ничего, кроме разрешённого.
Я знал, что можно настраивать подобные ограничения через конфиг sshd и настройку ForceCommand, но с authorized_keys всё намного проще, быстрее, нагляднее.
Возникла ещё одна идея, где это может быть удобно. Если сами настраиваете bastion host или jump host, по разному может называться. Суть в том, что только через этот хост можно подключаться к другим серверам. Можно сделать учётки, для которых будет разрешено подключение к какому-то конкретному серверу. А параметры подключения прописать сразу в command. При подключении по ssh на jump host, пользователь сразу окажется на нужном сервере. Сразу готова и система ограничения доступа, и логирования на базе sshd.
Подробнее об этой настройке можно прочитать в документации к sshd.
#ssh
В файл authorized_keys перед самим сертификатом добавляем разрешённую команду:
command="top" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAt....И больше ничего не надо делать. Подключившийся, кроме top, ничего запустить не сможет. Команда top запустится автоматически при успешном подключении. Я просто пример привёл, как быстро протестировать возможность.
На практике это очень пригодится для служебных учётных записей, которые ходят по серверам и выполняют какие-то заскриптованные действия. Например, делают дамбы баз, запускают скрипты бэкапа и т.д. Достаточно просто добавить ограничение в виде command и учётная запись не сможет сделать ничего, кроме разрешённого.
Я знал, что можно настраивать подобные ограничения через конфиг sshd и настройку ForceCommand, но с authorized_keys всё намного проще, быстрее, нагляднее.
Возникла ещё одна идея, где это может быть удобно. Если сами настраиваете bastion host или jump host, по разному может называться. Суть в том, что только через этот хост можно подключаться к другим серверам. Можно сделать учётки, для которых будет разрешено подключение к какому-то конкретному серверу. А параметры подключения прописать сразу в command. При подключении по ssh на jump host, пользователь сразу окажется на нужном сервере. Сразу готова и система ограничения доступа, и логирования на базе sshd.
Подробнее об этой настройке можно прочитать в документации к sshd.
#ssh
Хочу подкинуть вам идею, которая может когда-нибудь пригодиться. Подключение к NFS серверу можно организовать через проброс портов по SSH и это нормально работает. Когда есть sshfs, может показаться, что в этом нет никакого смысла. Могу привести свой пример, когда мне это пригодилось.
Мне нужно было перекинуть бэкапы виртуалок с внешнего сервера Proxmox домой на мой NFS сервер. Тут вариант либо порты пробрасывать на домашний сервер, но это если у тебя белый IP, либо как раз воспользоваться пробросом портов, подключившись из дома к внешнему серверу по SSH.
Настраивать тут особо ничего не надо. Если NFS сервер уже настроен, то достаточно сделать обратный проброс локального порта 2049 на внешний сервер:
Если на той стороне уже есть nfs сервер и порт 2049 занят, то можно указать другой. Только надо аккуратно поменять ровно то, что нужно. Я обычно путаюсь в пробросе портов по SSH, так как тут неинтуитивно. Должно быть вот так:
Останется только на удалённом сервере подмонтировать том:
Тут ещё стоит понимать, что nfs и sshfs принципиально разные вещи. Первое — это полноценная сетевая файловая система со своими службами, хранением метаданных и т.д., а второе — реализация доступа к файлам по протоколу SFTP на базе FUSE (Filesystem in Userspace). SFTP обычно используется для разовой передачи файлов. NFS же можно ставить на постоянку. Это стабильное решение (но не через SSH 😀).
#nfs #ssh #fileserver
Мне нужно было перекинуть бэкапы виртуалок с внешнего сервера Proxmox домой на мой NFS сервер. Тут вариант либо порты пробрасывать на домашний сервер, но это если у тебя белый IP, либо как раз воспользоваться пробросом портов, подключившись из дома к внешнему серверу по SSH.
Настраивать тут особо ничего не надо. Если NFS сервер уже настроен, то достаточно сделать обратный проброс локального порта 2049 на внешний сервер:
# ssh -R 2049:127.0.0.1:2049 root@server-ipЕсли на той стороне уже есть nfs сервер и порт 2049 занят, то можно указать другой. Только надо аккуратно поменять ровно то, что нужно. Я обычно путаюсь в пробросе портов по SSH, так как тут неинтуитивно. Должно быть вот так:
# ssh -R 3049:127.0.0.1:2049 root@server-ipОстанется только на удалённом сервере подмонтировать том:
# mount -t nfs -o port=3049 localhost:/data /mnt/nfs-shareТут ещё стоит понимать, что nfs и sshfs принципиально разные вещи. Первое — это полноценная сетевая файловая система со своими службами, хранением метаданных и т.д., а второе — реализация доступа к файлам по протоколу SFTP на базе FUSE (Filesystem in Userspace). SFTP обычно используется для разовой передачи файлов. NFS же можно ставить на постоянку. Это стабильное решение (но не через SSH 😀).
#nfs #ssh #fileserver
Я уже не однократно затрагивал тему логирования сессий пользователей на Linux сервере. Все способы сильно отличаются друг от друга, так что каждый может выбрать то, что подходит ему больше в конкретной ситуации. Напомню, о чём я уже рассказывал:
◽️snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND — логирование в текстовый файл с помощью встроенных возможностей оболочки bash.
Сейчас хочу рассказать о более серьезной программе, которая написана RedHat и интегрирована в их экосистему. Речь пойдёт про Tlog. Под остальные линуксы нужно будет самостоятельно собирать из исходников. Хотя я посмотрел в момент написания статьи, как дела обстоят в Debian, и заметил, что этот пакет в 12-й версии уже в ветке Testing. Так что со временем и для Debian должен появиться пакет.
Tlog умеет хранить сессии пользователей в текстовых файлах через rsyslog, в журнале systemd или в elasticsearch. Формат хранения — json, так что вручную такие логи смотреть не удобно. В комплекте с tlog есть утилита для воспроизведения сохранённой сессии. Причём можно как запись смотреть, так и в режиме реального времени. Если сессии хранятся локально, то за сеансом можно следить в соседней консоли, если в elasticsearch, то подключившись к нему. Посмотреть, как это выглядит на практике можно в демонстрационном ролике.
Tlog в RHEL или Centos, а также всех форках, интегрирован с SSSD и Cockpit. У redhat есть статья с описанием, как это реализовано. Если коротко, то ставим cockpit и tlog. Настраиваем в sssd запись сессии, назначаем группу, для которой она будет работать. Потом пользователей добавляем в эту группу и смотрим записи их сессий через веб интерфейс cockpit. Там это реализовано в виде плеера.
Поддержка elasticsearch реализована с помощью модуля omelasticsearch для rsyslog. То есть логи надо будет сначала в rsyslog положить, а потом он отправит их в elasticsearch. А встроенная поддержка этого дела заключается в том, что потом можно будет просматривать сессии, подключаясь напрямую в elasticsearch. Пример настройки и просмотра показан в репозитории.
В общем, если вам нужно централизованное решение для логирования пользовательских сессий, то Tlog будет лучшим вариантом. С настройкой придётся повозиться, но получится полноценное решение, основанное на пользователях и группах с помощью интеграции с FreeIPA через SSSD. Забыл сразу упомянуть об этом.
⇨ Сайт / Исходники / Настройка / Демонстрация
#security #ssh #linux
◽️snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND — логирование в текстовый файл с помощью встроенных возможностей оболочки bash.
Сейчас хочу рассказать о более серьезной программе, которая написана RedHat и интегрирована в их экосистему. Речь пойдёт про Tlog. Под остальные линуксы нужно будет самостоятельно собирать из исходников. Хотя я посмотрел в момент написания статьи, как дела обстоят в Debian, и заметил, что этот пакет в 12-й версии уже в ветке Testing. Так что со временем и для Debian должен появиться пакет.
Tlog умеет хранить сессии пользователей в текстовых файлах через rsyslog, в журнале systemd или в elasticsearch. Формат хранения — json, так что вручную такие логи смотреть не удобно. В комплекте с tlog есть утилита для воспроизведения сохранённой сессии. Причём можно как запись смотреть, так и в режиме реального времени. Если сессии хранятся локально, то за сеансом можно следить в соседней консоли, если в elasticsearch, то подключившись к нему. Посмотреть, как это выглядит на практике можно в демонстрационном ролике.
Tlog в RHEL или Centos, а также всех форках, интегрирован с SSSD и Cockpit. У redhat есть статья с описанием, как это реализовано. Если коротко, то ставим cockpit и tlog. Настраиваем в sssd запись сессии, назначаем группу, для которой она будет работать. Потом пользователей добавляем в эту группу и смотрим записи их сессий через веб интерфейс cockpit. Там это реализовано в виде плеера.
Поддержка elasticsearch реализована с помощью модуля omelasticsearch для rsyslog. То есть логи надо будет сначала в rsyslog положить, а потом он отправит их в elasticsearch. А встроенная поддержка этого дела заключается в том, что потом можно будет просматривать сессии, подключаясь напрямую в elasticsearch. Пример настройки и просмотра показан в репозитории.
В общем, если вам нужно централизованное решение для логирования пользовательских сессий, то Tlog будет лучшим вариантом. С настройкой придётся повозиться, но получится полноценное решение, основанное на пользователях и группах с помощью интеграции с FreeIPA через SSSD. Забыл сразу упомянуть об этом.
⇨ Сайт / Исходники / Настройка / Демонстрация
#security #ssh #linux
Очень простой и быстрый способ настроить уведомления об успешном SSH подключении к серверу в Telegram. Для этого понадобится свой bot, простенький bash скрипт и изменение конфига PAM для SSH. Будем через него уведомления делать.
Рассказывать про создание бота не буду. Надо создать нового бота, получить его токен. Также понадобится ваш ID. Узнать можно разными способами, например через бота @my_id_bot.
Далее берём простой скрипт:
Тут мы проверяем переменную PAM_TYPE. Если это что-то отличное от закрытия сессии, то нам подходит. Проверить работу скрипта можно примерно так:
От бота вам должно прийти уведомление в указанном выше формате. Только имени пользователя не будет, потому что переменную PAM_USER не задали.
Копируем этот скрипт в директорию /etc/ssh/ и выставляем минимальные права:
Далее открываем конфиг
На этом всё. Теперь при успешном SSH подключении вы будете получать уведомление в Telegram.
По аналогии с этим скриптом, вы можете сделать уведомления и на другие события. Например, на закрытие сессии, или на неудачную аутентификацию.
Единственное, что мне хотелось бы сделать, но не получилось - вывести в уведомление IP адрес подключившегося пользователя. Я не нашёл в переменных PAM этой информации. А парсить лог ssh подключений не захотелось. Это делает решение неуниверсальным. В представленном виде сообщения будут такие:
2023-08-07, Monday 15:10
SSH Login: root@debian11
Подробная дата (date +"%Y-%m-%d, %A %R"), имя пользователя ($PAM_USER) и имя сервера (hostname). Можете добавить какую-то ещё информацию по своему усмотрению. Если кто-то знает переменную PAM с информацией об адресе подключившегося, подскажите. Я не нашёл такой информации.
#linux #bash #ssh #security
Рассказывать про создание бота не буду. Надо создать нового бота, получить его токен. Также понадобится ваш ID. Узнать можно разными способами, например через бота @my_id_bot.
Далее берём простой скрипт:
#!/bin/bashif [ "$PAM_TYPE" != "close_session" ]; then ID=1307682341 BOT_TOKEN=6327355747:AAEDcFIlhKSIOKS-t2I9ARTdT1usbq2a9W4 message="$(date +"%Y-%m-%d, %A %R")"$'\n'"SSH Login: $PAM_USER@$(hostname)" curl -s --data "text=$message" --data "chat_id=$ID" 'https://api.telegram.org/bot'$BOT_TOKEN'/sendMessage' > /dev/nullfiТут мы проверяем переменную PAM_TYPE. Если это что-то отличное от закрытия сессии, то нам подходит. Проверить работу скрипта можно примерно так:
# PAM_TYPE=open_session ./ssh-success.shОт бота вам должно прийти уведомление в указанном выше формате. Только имени пользователя не будет, потому что переменную PAM_USER не задали.
Копируем этот скрипт в директорию /etc/ssh/ и выставляем минимальные права:
# chown root /etc/ssh/ssh-success.sh# chmod 100 /etc/ssh/ssh-success.shДалее открываем конфиг
/etc/pam.d/sshd и добавляем туда:# Send a login notification to Telegram via ssh-success.shsession optional pam_exec.so seteuid /etc/ssh/ssh-success.shНа этом всё. Теперь при успешном SSH подключении вы будете получать уведомление в Telegram.
По аналогии с этим скриптом, вы можете сделать уведомления и на другие события. Например, на закрытие сессии, или на неудачную аутентификацию.
Единственное, что мне хотелось бы сделать, но не получилось - вывести в уведомление IP адрес подключившегося пользователя. Я не нашёл в переменных PAM этой информации. А парсить лог ssh подключений не захотелось. Это делает решение неуниверсальным. В представленном виде сообщения будут такие:
2023-08-07, Monday 15:10
SSH Login: root@debian11
Подробная дата (date +"%Y-%m-%d, %A %R"), имя пользователя ($PAM_USER) и имя сервера (hostname). Можете добавить какую-то ещё информацию по своему усмотрению. Если кто-то знает переменную PAM с информацией об адресе подключившегося, подскажите. Я не нашёл такой информации.
#linux #bash #ssh #security
Существует удобный инструмент для поддержания постоянного подключения по SSH - Autossh. Это бесплатная программа, которая есть в стандартных репозиториях популярных дистрибутивов.
Autossh отслеживает SSH соединение, и если оно разрывается, переподключает. Я не знаю, где это может быть полезно, кроме как в случаях использования туннелей или проброса портов через SSH. Покажу на примере, как это работает.
Допустим, у вас есть какой-то сервер в интернете с внешним IP адресом. И вы хотите превратить его в jump хост, подключаясь через него к другим серверам в закрытом сегменте без прямого доступа к ним через интернет.
Настраиваем доступ с закрытых хостов к внешнему серверу через ключи. Проверяем в ручном режиме, что они работают. Для SSH туннелей как на внешнем сервере, так и на внутренних, можно создать отдельного пользователя. Это необязательно, но так будет удобнее и безопаснее. Shell ему можно не назначать, указав nologin.
Сначала просто проверяем соединение:
Синтаксис тут один в один как у обычной службы sshd в том, что касается ssh соединения. То есть выполняем стандартный обратный проброс через ssh. Локальный порт 22 пробрасываем на удалённый хост 1.1.1.1 на порт 9033. Опции autossh можете посмотреть в его описании. Не буду на этом подробно останавливаться.
Теперь можно подключиться к внешнему серверу и на нём подключиться к внутреннему серверу:
Окажетесь на закрытом сервере, на котором запустили autossh.
Теперь сделаем всё красиво, запуская autossh через systemd под отдельной учётной записью. Создаём юнит
Запускаем и добавляем в автозагрузку:
Проверяем на внешнем сервере:
Всё работает. Заходим на внешний сервер и через его консоль подключаемся к закрытым серверам. Подобным образом можно настроить постоянное подключение NFS сервера по SSH.
По необходимости можно ограничивать разрешённые команды по ssh, либо настроить логирование действий.
#ssh
# apt install autosshAutossh отслеживает SSH соединение, и если оно разрывается, переподключает. Я не знаю, где это может быть полезно, кроме как в случаях использования туннелей или проброса портов через SSH. Покажу на примере, как это работает.
Допустим, у вас есть какой-то сервер в интернете с внешним IP адресом. И вы хотите превратить его в jump хост, подключаясь через него к другим серверам в закрытом сегменте без прямого доступа к ним через интернет.
Настраиваем доступ с закрытых хостов к внешнему серверу через ключи. Проверяем в ручном режиме, что они работают. Для SSH туннелей как на внешнем сервере, так и на внутренних, можно создать отдельного пользователя. Это необязательно, но так будет удобнее и безопаснее. Shell ему можно не назначать, указав nologin.
Сначала просто проверяем соединение:
# autossh -M 0 -N -p 22777 -f -q -i /home/userssh/.ssh/id_rsa \-o "ExitOnForwardFailure=yes" -o "ServerAliveInterval=30" \-o "ServerAliveCountMax=3" -R 9033:localhost:22 \userssh@1.1.1.1Синтаксис тут один в один как у обычной службы sshd в том, что касается ssh соединения. То есть выполняем стандартный обратный проброс через ssh. Локальный порт 22 пробрасываем на удалённый хост 1.1.1.1 на порт 9033. Опции autossh можете посмотреть в его описании. Не буду на этом подробно останавливаться.
Теперь можно подключиться к внешнему серверу и на нём подключиться к внутреннему серверу:
# ssh -p 9033 root@localhost Окажетесь на закрытом сервере, на котором запустили autossh.
Теперь сделаем всё красиво, запуская autossh через systemd под отдельной учётной записью. Создаём юнит
/etc/systemd/system/autossh.service:[Unit]Description=SSH Reverse TunnelAfter=network-online.target[Service]Type=forkingUser=usersshExecStart=/usr/bin/autossh -M 0 -N -p 22777 -f -q -i /home/userssh/.ssh/id_rsa -o "ExitOnForwardFailure=yes" -o "ServerAliveInterval=30" -o "ServerAliveCountMax=3" -R 9033:localhost:22 userssh@1.1.1.1ExecStop=/usr/bin/pkill -9 -u usersshRestartSec=5Restart=always[Install]WantedBy=multi-user.targetЗапускаем и добавляем в автозагрузку:
# systemctl daemon-reload# systemctl start autossh.service# systemctl enable autossh.serviceПроверяем на внешнем сервере:
# netstat -tulnp | grep 9033tcp 0 0 127.0.0.1:9033 0.0.0.0:* LISTEN 19814/sshd: usersshtcp6 0 0 ::1:9033 :::* LISTEN 19814/sshd: usersshВсё работает. Заходим на внешний сервер и через его консоль подключаемся к закрытым серверам. Подобным образом можно настроить постоянное подключение NFS сервера по SSH.
По необходимости можно ограничивать разрешённые команды по ssh, либо настроить логирование действий.
#ssh
«Главная проблема цитат в интернете в том, что люди сразу верят в их подлинность», - Владимир Ленин.
Просматривал недавно общение в какой-то заметке с комментариями, а там подняли тему Fail2Ban и SSH, и в голове всплыла выдуманная цитата, приписываемая Салтыкову-Щедрину, хотя он её никогда не произносил: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: пьют и воруют». Она на самом деле новодел 90-х годов. Ни один из классиков её никогда не произносил, а в голове у меня она каким-то образом оказалась.
А вспомнил я её, потому что на все эти блокировки SSH у меня родился свой аналог этого выражения:
«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».
Я не знаю, зачем об этом до сих пор кто-то вспоминает, рекомендует или сам настраивает. Это было неактуально уже тогда, когда я сам начал изучать Linux.
Сервис SSH давно уже не брутится, потому что повсеместно распространены сертификаты, либо можно применить другие существующие настройки sshd: MaxAuthTries, MaxSessions, MaxStartups, которые делают брут фактически невозможным. Наверное стоит посвятить этому отдельную заметку. И никакой Fail2Ban тут не нужен. Я сам его использую, но не для SSH.
#ssh #fail2ban
Просматривал недавно общение в какой-то заметке с комментариями, а там подняли тему Fail2Ban и SSH, и в голове всплыла выдуманная цитата, приписываемая Салтыкову-Щедрину, хотя он её никогда не произносил: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: пьют и воруют». Она на самом деле новодел 90-х годов. Ни один из классиков её никогда не произносил, а в голове у меня она каким-то образом оказалась.
А вспомнил я её, потому что на все эти блокировки SSH у меня родился свой аналог этого выражения:
«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».
Я не знаю, зачем об этом до сих пор кто-то вспоминает, рекомендует или сам настраивает. Это было неактуально уже тогда, когда я сам начал изучать Linux.
Сервис SSH давно уже не брутится, потому что повсеместно распространены сертификаты, либо можно применить другие существующие настройки sshd: MaxAuthTries, MaxSessions, MaxStartups, которые делают брут фактически невозможным. Наверное стоит посвятить этому отдельную заметку. И никакой Fail2Ban тут не нужен. Я сам его использую, но не для SSH.
#ssh #fail2ban
Смотрите, какая прикольна штука есть для подключения по SSH из консоли - sshto. Это небольшой bash скрипт, который позволяет через псевдографическое меню управлять преднастроенными SSH подключениями. Хорошее решение для самодельного jumphost.
Это когда вы используете промежуточный сервер для подключения к целевым серверам. Такой подход позволяет гибко управлять доступом на основе пользователей jump севера, логировать команды и записывать вывод консоли. И всё без каких-то специализированных решений. В основном средствами самого Linux и его небольших утилит. У меня в разное время были различные заметки по этой теме. Если интересно, могу собрать их в одну.
Вернёмся к sshto. Как я уже сказал, это bash скрипт, который читает конфигурацию из файла
Ставим sshto:
Запускаем:
Видим меню, такое же как, в приложенной картинке. Помимо непосредственно подключений по SSH, скрипт умеет там же, на удалённых серверах, сразу же выполнять некоторые команды.
#ssh #bash #script
Это когда вы используете промежуточный сервер для подключения к целевым серверам. Такой подход позволяет гибко управлять доступом на основе пользователей jump севера, логировать команды и записывать вывод консоли. И всё без каких-то специализированных решений. В основном средствами самого Linux и его небольших утилит. У меня в разное время были различные заметки по этой теме. Если интересно, могу собрать их в одну.
Вернёмся к sshto. Как я уже сказал, это bash скрипт, который читает конфигурацию из файла
~/.ssh/config и выводит список серверов оттуда в псевдографическое меню. Вот пример такого файла:#Host DUMMY #Moscow#Host server-number-one #First ServerHostName 1.2.3.4port 22777user rootHost server-number-two #Second serverHostName 4.3.2.1port 22888user username#Host DUMMY #Saint Petersburg#Host server-number-three #Third serverHostName 5.6.7.8port 22user user01Host server-number-four #Fourth serverHostName 9.8.7.6port 22user user02Ставим sshto:
# git clone https://github.com/vaniacer/sshto# cd sshto/# cp sshto /usr/bin/Запускаем:
# sshtoВидим меню, такое же как, в приложенной картинке. Помимо непосредственно подключений по SSH, скрипт умеет там же, на удалённых серверах, сразу же выполнять некоторые команды.
#ssh #bash #script
Я по привычке всегда создаю ключи для SSH с использованием протокола RSA. Просто добавляю параметр для длины ключа 4096. Когда-то увидел информацию, что меньшая длина теоретически может быть небезопасной.
OpenSSH сервер в очередном обновлении отказался от коротких RSA ключей: "Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.". А не так давно от него было предупреждение: "use RSA/SHA256 when testing usability of private keys as some systems are starting to disable RSA/SHA1 in libcrypto." Это всё информация из releasenotes.
Криптография не стоит на месте и постоянно развивается. Появился протокол Ed25519, который сейчас многие сервисы рекомендую использовать для SSH ключей, а если видят RSA, то выводят предупреждение. Не вижу причин его не использовать. Надо менять привычки.
Явным плюсом Ed25519 является то, что и приватный, и публичный ключи получаются значительно короче. То есть из чисто практических соображений ими удобнее пользоваться.
Публичные ключи Ed заметно короче RSA, что банально практичнее. Они содержат всего 68 символов, в отличие от RSA 3072 с их длиной 544 символа.
Кто-то уже перешёл на Ed25519? Там нет каких-то подводных камней, в виде отсутствия поддержки в каком-то софте? По идее, такого уже не должно быть, так как алгоритм появился довольно давно. Хотя какой тут софт может быть? Подавляющее число подключений по SSH, это подключения к openssh серверу, который с 15-го года поддерживает Ed25519. Наиболее вероятно, что проблемы могут возникнуть на каком-то старом сетевом оборудовании, где версия openssh очень старая.
#ssh
# ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)_$(date -I)"OpenSSH сервер в очередном обновлении отказался от коротких RSA ключей: "Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.". А не так давно от него было предупреждение: "use RSA/SHA256 when testing usability of private keys as some systems are starting to disable RSA/SHA1 in libcrypto." Это всё информация из releasenotes.
Криптография не стоит на месте и постоянно развивается. Появился протокол Ed25519, который сейчас многие сервисы рекомендую использовать для SSH ключей, а если видят RSA, то выводят предупреждение. Не вижу причин его не использовать. Надо менять привычки.
Явным плюсом Ed25519 является то, что и приватный, и публичный ключи получаются значительно короче. То есть из чисто практических соображений ими удобнее пользоваться.
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"# cat id_ed25519-----BEGIN OPENSSH PRIVATE KEY-----b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisnjwAAAKCDHZihgx2YoQAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisxjwAAAECp2CJm9zWAsi9TQ/T92h6maR7CkeZyXlR1EOC9IecDvCFB44opd6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGPAAAAGHJvb3RAZGViaWFuMTFfMjAyMy0xMi0yMAECAwQF-----END OPENSSH PRIVATE KEY-----# cat id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICFB44opv6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGP root@debian11_2023-12-20Публичные ключи Ed заметно короче RSA, что банально практичнее. Они содержат всего 68 символов, в отличие от RSA 3072 с их длиной 544 символа.
Кто-то уже перешёл на Ed25519? Там нет каких-то подводных камней, в виде отсутствия поддержки в каком-то софте? По идее, такого уже не должно быть, так как алгоритм появился довольно давно. Хотя какой тут софт может быть? Подавляющее число подключений по SSH, это подключения к openssh серверу, который с 15-го года поддерживает Ed25519. Наиболее вероятно, что проблемы могут возникнуть на каком-то старом сетевом оборудовании, где версия openssh очень старая.
#ssh
Много раз писал про различные возможности SSH на сервере, в том числе для использования в роли jumphost. Да и сам нередко использовал эту возможность. При этом либо в 2 этапа подключался к требуемому хосту, то есть вручную - сначала на jumphost, потом уже на целевой. Либо запускал команду на подключение к целевому хосту внутри команды на подключение к jumphost:
Особенность такого последовательного подключения в том, что к jumphost вы подключаетесь, используя свой сертификат на локальной машине, а с jumphost на server01 используя сертификат с сервера jumphost. Они могут быть как одинаковыми, так и разными. Происходит последовательное подключение сначала к первому хосту по ssh, потом с первого ко второму в рамках первой ssh сессии.
Мимо моего внимания прошла возможность ssh напрямую подключаться со своего хоста на server01 через jumphost. То есть это выглядит вот так:
Для этого даже отдельный ключ есть
Оба эти подхода имеют право на жизнь, в зависимости от ваших потребностей. Например, при первом подходе на jumphost можно более гибко раздать права, настроить логирование или запись сессий, уведомления о подключениях. В случае второго подхода всё это придётся делать на целевом сервере, но при этом будет более простое и стабильное соединение, так как ssh сессия будет одна, а не вложение одной в другую.
📌 Ссылки по теме:
▪ Логирование ssh активности с помощью: Tlog, snoopy, log-user-session, PROMPT_COMMAND
▪ Уведомления в Telegram о ssh сессиях
▪ Переадресация портов через ssh
▪ VPN туннели с помощью ssh
▪ Ограничение на выполнение команд по ssh
▪ Псевдографическое меню для jumphost
▪ Поддержание постоянного ssh соединения с помощью Autossh
#ssh
# ssh -t user@jumphost "ssh user@server01"Особенность такого последовательного подключения в том, что к jumphost вы подключаетесь, используя свой сертификат на локальной машине, а с jumphost на server01 используя сертификат с сервера jumphost. Они могут быть как одинаковыми, так и разными. Происходит последовательное подключение сначала к первому хосту по ssh, потом с первого ко второму в рамках первой ssh сессии.
Мимо моего внимания прошла возможность ssh напрямую подключаться со своего хоста на server01 через jumphost. То есть это выглядит вот так:
# ssh -J user@jumphost:22 user@server01Для этого даже отдельный ключ есть
-J. Это принципиально другой тип подключения, так как при этом пробрасывается TCP порт через jumphost. Подключение происходит напрямую с твоей машины. Ключ, соответственно, проверяется только у тебя.Оба эти подхода имеют право на жизнь, в зависимости от ваших потребностей. Например, при первом подходе на jumphost можно более гибко раздать права, настроить логирование или запись сессий, уведомления о подключениях. В случае второго подхода всё это придётся делать на целевом сервере, но при этом будет более простое и стабильное соединение, так как ssh сессия будет одна, а не вложение одной в другую.
📌 Ссылки по теме:
▪ Логирование ssh активности с помощью: Tlog, snoopy, log-user-session, PROMPT_COMMAND
▪ Уведомления в Telegram о ssh сессиях
▪ Переадресация портов через ssh
▪ VPN туннели с помощью ssh
▪ Ограничение на выполнение команд по ssh
▪ Псевдографическое меню для jumphost
▪ Поддержание постоянного ssh соединения с помощью Autossh
#ssh
▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Как раз к выходным.
▪ Прохождение #Linux-машины DRIVE.HTB, сложного уровня | #HackTheBox
Новое прохождение задания на Hackthebox по взлому операционной системы. Не буду подробно описывать видео. Оно по структуре и тематике такое же как прошлое, где я подробно разобрал, о чём там речь. Только тут задача посложнее и подольше. Смотреть интересно, но только если понимаешь, что там происходит. В целом, контент очень качественный, рекомендую.
▪ Как в Synology просто и быстро развернуть несколько сайтов в пару кликов
Автор рассказывает, как в Synology настроить веб сервер и захостить там сайты. Когда-то давным-давно мой сайт некоторое время жил у меня в квартире на Synology. В целом, работал нормально, но мне быстро надоел постоянно работающий сервер. Убрал сайт на хостинг, а NAS стал периодически выключать.
▪ Организация компьютерных сетей
▪ Терминология сетей
Андрей Созыкин начал работу над новой актуальной версией курса по компьютерным сетям. Первые уроки уже смонтированы, можно посмотреть.
▪ Proxmox Установка и обзор функций WebUI
Простая установка и разбор возможностей веб интерфейса Proxmox. Конкретно в этом видео ничего особо нового и интересного нет. Автор обещает дальше настройку кластера, настройку бэкапов в PBS. Так что имеет смысл подписаться и следить, если интересна эта тема.
▪ Monitor Storage S.M.A.R.T With ZABBIX - Tutorial
Инструкция от Dmitry Lambert о том, как мониторить показатели SMART с помощью Zabbix agent 2. В инструкции он показывает на примере системы Windows. То есть это решение в основном для мониторинга за рабочими станциями.
🔥Running Windows in a Docker Container!
История о том, как на Linux запустить любую версию Windows с помощью Docker контейнера и зайти в неё через браузер. Сначала подумал, что за магия? На самом деле никакой магии. Контейнер поднимает KVM, создаёт виртуалку и запускает. Весь процесс автоматизирован. По этой теме имеет смысл сделать отдельную публикацию с описанием. Очень интересное решение получилось. Я пока только посмотрел, сам не пробовал запускать.
Если посмотрите видео, то не забудьте зайти в комментарии и поблагодарить авторов. Вам это ничего не стоит, а им приятно.
#видео
▪ Прохождение #Linux-машины DRIVE.HTB, сложного уровня | #HackTheBox
Новое прохождение задания на Hackthebox по взлому операционной системы. Не буду подробно описывать видео. Оно по структуре и тематике такое же как прошлое, где я подробно разобрал, о чём там речь. Только тут задача посложнее и подольше. Смотреть интересно, но только если понимаешь, что там происходит. В целом, контент очень качественный, рекомендую.
▪ Как в Synology просто и быстро развернуть несколько сайтов в пару кликов
Автор рассказывает, как в Synology настроить веб сервер и захостить там сайты. Когда-то давным-давно мой сайт некоторое время жил у меня в квартире на Synology. В целом, работал нормально, но мне быстро надоел постоянно работающий сервер. Убрал сайт на хостинг, а NAS стал периодически выключать.
▪ Организация компьютерных сетей
▪ Терминология сетей
Андрей Созыкин начал работу над новой актуальной версией курса по компьютерным сетям. Первые уроки уже смонтированы, можно посмотреть.
▪ Proxmox Установка и обзор функций WebUI
Простая установка и разбор возможностей веб интерфейса Proxmox. Конкретно в этом видео ничего особо нового и интересного нет. Автор обещает дальше настройку кластера, настройку бэкапов в PBS. Так что имеет смысл подписаться и следить, если интересна эта тема.
▪ Monitor Storage S.M.A.R.T With ZABBIX - Tutorial
Инструкция от Dmitry Lambert о том, как мониторить показатели SMART с помощью Zabbix agent 2. В инструкции он показывает на примере системы Windows. То есть это решение в основном для мониторинга за рабочими станциями.
🔥Running Windows in a Docker Container!
История о том, как на Linux запустить любую версию Windows с помощью Docker контейнера и зайти в неё через браузер. Сначала подумал, что за магия? На самом деле никакой магии. Контейнер поднимает KVM, создаёт виртуалку и запускает. Весь процесс автоматизирован. По этой теме имеет смысл сделать отдельную публикацию с описанием. Очень интересное решение получилось. Я пока только посмотрел, сам не пробовал запускать.
Если посмотрите видео, то не забудьте зайти в комментарии и поблагодарить авторов. Вам это ничего не стоит, а им приятно.
#видео
YouTube
Прохождение #Linux-машины DRIVE.HTB, сложного уровня | #HackTheBox | КАК ПРОЙТИ #DRIVE.HTB
Как решить машину DRIVE на HackTheBox?
Drive — это сложная(средняя) машина Linux, которая включает в себя сервис обмена файлами, подверженный уязвимости #IDOR (Insecure Direct Object Reference), через который обнаруживается простой текстовый пароль, приводящий…
Drive — это сложная(средняя) машина Linux, которая включает в себя сервис обмена файлами, подверженный уязвимости #IDOR (Insecure Direct Object Reference), через который обнаруживается простой текстовый пароль, приводящий…
Расскажу вам про один любопытный инструмент, который часто используют либо пентестеры, либо хакеры, чтобы закрепиться в чужой инфраструктуре. А так как это всё напрямую связано с системным администрированием, то инструмент может пригодиться и в обычных делах. Благо он очень простой для использования и освоения, поэтому относительно популярный. По нему много информации в англоязычном интернете.
Речь пойдёт про Chisel — это TCP/UDP туннель, который работает поверх HTTP с использованием SSH. Причём представляет он из себя один бинарник, написанный на GO. Один и тот же файл и для сервера, и для клиента, работает под всеми популярными системами. То есть вы можете поднять сервер на Windows, а подключиться клиентом с Linux и наоборот. Благодаря тому, что chisel работает поверх HTTP, вы очень быстро и просто можете поднять необходимый туннель там, где этот протокол открыт. Покажу сразу на примерах.
1️⃣ Пример, который в настоящее время очень актуален. Быстро поднимаем SOCKS5 прокси, через который будем выходить в интернет. Качаем бинарник под свою систему из репозитория:
Делаем его исполняемым и запускаем сервер:
Подключаемся с Windows машины:
Теперь идём в браузер и настраиваем socks прокси: адрес - 127.0.0.1, порт 1080. Проверяем на любом сервисе для определения ip адреса. Браузер должен выходить в интернет через IP адрес сервера. Можно добавить аутентификацию:
Очень просто и быстро. Не нужны никакие VPN туннели. Оставляем отдельный браузер под эту прокси и выходим по мере нужды в интернет через него.
2️⃣ Ещё пример. Допустим, мы хотим подключиться по SSH к машине, к которой нет доступа извне, но сама она может по HTTP стучаться наружу. Очень часто HTTP протокол открыт хотя бы для того, чтобы качать обновления на сервер или для каких-то других нужд. Берём любой свой сервер, к которому есть прямой доступ через интернет и запускаем там chisel. Если свободен 80-й порт, можно прямо на нём. Если нет, то выбираем любой другой.
Теперь идём на закрытый сервер, качаем туда бинарник под свою систему и подключаемся как клиент к серверу, где мы до этого запустили chisel:
При подключении клиента будет создан обратный туннель с 2222 порта сервера на 22-й порт клиента. Теперь, чтобы подключиться по SSH к клиенту, достаточно выполнить на сервере:
и ввести учётные данные от клиента. Таким образом, не имея прямого доступа к клиенту, мы подключились по SSH к нему с использованием обратного туннеля по HTTP, который клиент инициировал сам.
3️⃣ Обратный пример, когда мы хотим не с сервера подключиться к клиенту, а с клиента подключиться к какому-то сервису на сервере, доступ к которому напрямую закрыт. Допустим, на сервере крутился mysql на 127.0.0.1:3306. Мы хотим к нему напрямую подключиться с клиента. Запускаем так же сервер:
Подключаемся к нему клиентом:
Теперь с клиента вы можете подключиться к mysql серверу:
Попадёте в консоль сервера, к которому подключились клиентом.
Те, кто активно пользуются возможностями SSH, думаю, уже поняли, что это все те же возможности протокола SSH, только обёрнутые в HTTP через chisel. Про то, как то же самое делать напрямую через SSH я писал ранее:
⇨ SOCKS-прокси через ssh и переадресация портов
Chisel умеет маскировать себя. Для этого есть ключ
⇨ Исходники
#vpn #ssh
Речь пойдёт про Chisel — это TCP/UDP туннель, который работает поверх HTTP с использованием SSH. Причём представляет он из себя один бинарник, написанный на GO. Один и тот же файл и для сервера, и для клиента, работает под всеми популярными системами. То есть вы можете поднять сервер на Windows, а подключиться клиентом с Linux и наоборот. Благодаря тому, что chisel работает поверх HTTP, вы очень быстро и просто можете поднять необходимый туннель там, где этот протокол открыт. Покажу сразу на примерах.
1️⃣ Пример, который в настоящее время очень актуален. Быстро поднимаем SOCKS5 прокси, через который будем выходить в интернет. Качаем бинарник под свою систему из репозитория:
# wget https://github.com/jpillora/chisel/releases/download/v1.9.1/chisel_1.9.1_linux_amd64.gzДелаем его исполняемым и запускаем сервер:
# ./chisel server --port 80 --socks5Подключаемся с Windows машины:
> chisel.exe client http://<server-ip>:80 socksТеперь идём в браузер и настраиваем socks прокси: адрес - 127.0.0.1, порт 1080. Проверяем на любом сервисе для определения ip адреса. Браузер должен выходить в интернет через IP адрес сервера. Можно добавить аутентификацию:
# ./chisel server --port 80 --socks5 --auth user123:password321> chisel.exe client --auth user123:password321 http://188.227.57.126:80 socksОчень просто и быстро. Не нужны никакие VPN туннели. Оставляем отдельный браузер под эту прокси и выходим по мере нужды в интернет через него.
2️⃣ Ещё пример. Допустим, мы хотим подключиться по SSH к машине, к которой нет доступа извне, но сама она может по HTTP стучаться наружу. Очень часто HTTP протокол открыт хотя бы для того, чтобы качать обновления на сервер или для каких-то других нужд. Берём любой свой сервер, к которому есть прямой доступ через интернет и запускаем там chisel. Если свободен 80-й порт, можно прямо на нём. Если нет, то выбираем любой другой.
# ./chisel server -p 80 --reverseТеперь идём на закрытый сервер, качаем туда бинарник под свою систему и подключаемся как клиент к серверу, где мы до этого запустили chisel:
# ./chisel client http://<server-ip>:80 R:2222:localhost:22При подключении клиента будет создан обратный туннель с 2222 порта сервера на 22-й порт клиента. Теперь, чтобы подключиться по SSH к клиенту, достаточно выполнить на сервере:
# ssh -p 2222 root@127.0.0.1и ввести учётные данные от клиента. Таким образом, не имея прямого доступа к клиенту, мы подключились по SSH к нему с использованием обратного туннеля по HTTP, который клиент инициировал сам.
3️⃣ Обратный пример, когда мы хотим не с сервера подключиться к клиенту, а с клиента подключиться к какому-то сервису на сервере, доступ к которому напрямую закрыт. Допустим, на сервере крутился mysql на 127.0.0.1:3306. Мы хотим к нему напрямую подключиться с клиента. Запускаем так же сервер:
# ./chisel server -p 80 --reverseПодключаемся к нему клиентом:
# ./chisel client http://<server-ip>:80 33306:localhost:3306Теперь с клиента вы можете подключиться к mysql серверу:
# mysql -h 127.0.0.1 -P 33306 -u rootПопадёте в консоль сервера, к которому подключились клиентом.
Те, кто активно пользуются возможностями SSH, думаю, уже поняли, что это все те же возможности протокола SSH, только обёрнутые в HTTP через chisel. Про то, как то же самое делать напрямую через SSH я писал ранее:
⇨ SOCKS-прокси через ssh и переадресация портов
Chisel умеет маскировать себя. Для этого есть ключ
--backend Если на сервер приходит обычный HTTP запрос, не от клиента, он может перенаправить его на web сервер.⇨ Исходники
#vpn #ssh
Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.
Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:
Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.
Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:
Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:
Проверяем, что порт проброшен:
Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг
И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.
Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации.
Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:
Теперь можно забрать образ последней версии и запустить его:
После того, как всё скачано и запущено, настройки прокси можно отключить.
Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.
#elk #ssh #docker
Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:
# apt install privoxyБольше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.
Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:
# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.debHTTP request sent, awaiting response... 403 ForbiddenДоступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:
# ssh -L 3128:localhost:8118 root@1.2.3.4Проверяем, что порт проброшен:
# ss -tulnp | grep 3128tcp LISTEN 0 128 127.0.0.1:3128 0.0.0.0:* users:(("ssh",pid=1350,fd=5))Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг
~/.wgetrc:use_proxy=yeshttp_proxy=127.0.0.1:3128https_proxy=127.0.0.1:3128И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.
Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации.
# mkdir -p /etc/systemd/system/docker.service.d# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf[Service]Environment="HTTP_PROXY=http://127.0.0.1:3128"Environment="HTTPS_PROXY=http://127.0.0.1:3128" # systemctl daemon-reload # systemctl restart dockerОбращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:
# systemctl show --property=Environment dockerEnvironment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128Теперь можно забрать образ последней версии и запустить его:
# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2# docker run -d -e "discovery.type=single-node" \ -p 9200:9200 \ -p 9300:9300 \ docker.elastic.co/elasticsearch/elasticsearch:8.13.2После того, как всё скачано и запущено, настройки прокси можно отключить.
Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.
#elk #ssh #docker
Недавно один из подписчиков, видя мои посты про прокси по ssh, посоветовал расширение для браузера SwitchyOmega. Я когда-то давно искал подобное, но ничего не нашёл, что устроило бы меня. В итоге просто использовал разные браузеры под разные прокси.
Попробовал это расширение. Оно реально удобное. Позволяет по доменам раскидывать настройки. На одни домены ходим без прокси, на другие по одним настройкам, на другие по другим. Сделано просто и удобно. Особенно понравилось, что расширение может на сайте показать, какие ресурсы не были загружены и предложить добавить их в список ресурсов, доступных через прокси. На каких-то сайтах с множеством доменов под cdn это сильно упрощает задачу для формирования списка доменов.
Я уже мельком рассказывал, как использую прокси сам. Расскажу ещё раз поподробнее. У меня есть несколько VPS, к которым я могу подключаться по SSH с пробросом портов на локальную машину. Если нужен HTTP прокси, то пробрасываю порт установленной локально на VPS privoxy, если сойдёт и SOCKS, то напрямую подключаюсь через SSH с ключом -D.
На этих VPS открыт только SSH порт с доступом откуда угодно. Сами прокси в интернет не смотрят, поэтому там нет аутентификации, не надо отдельно следить за безопасностью этих прокси. На своей рабочей машине под Windows открываю WSL, там подключаюсь по SSH примерно так:
или так:
где 1.2.3.4 и 4.3.2.1 - IP VDS, а 192.168.99.2 - IP адрес внутри WSL. В браузере в качестве прокси указываю 192.168.99.2, порт 3128. В зависимости от подключенной VPS, работает та или иная локация для доступа в интернет.
Для сёрфинга или загрузки чего-либо мне такая схема кажется наиболее простой, безопасной и удобной в качестве обслуживания. Наружу торчат только SSH порты, что безопасно. Не привлекают к себе лишнего внимания, в отличие от открытых портов прокси. При этом я имею возможность подключаться к ним откуда угодно. И не нужно использовать VPN, которые иногда могут не работать.
В SwitchyOmega можно создавать разные профили настроек, переключаться между ними вручную или автоматически.
#ssh #proxy
Попробовал это расширение. Оно реально удобное. Позволяет по доменам раскидывать настройки. На одни домены ходим без прокси, на другие по одним настройкам, на другие по другим. Сделано просто и удобно. Особенно понравилось, что расширение может на сайте показать, какие ресурсы не были загружены и предложить добавить их в список ресурсов, доступных через прокси. На каких-то сайтах с множеством доменов под cdn это сильно упрощает задачу для формирования списка доменов.
Я уже мельком рассказывал, как использую прокси сам. Расскажу ещё раз поподробнее. У меня есть несколько VPS, к которым я могу подключаться по SSH с пробросом портов на локальную машину. Если нужен HTTP прокси, то пробрасываю порт установленной локально на VPS privoxy, если сойдёт и SOCKS, то напрямую подключаюсь через SSH с ключом -D.
На этих VPS открыт только SSH порт с доступом откуда угодно. Сами прокси в интернет не смотрят, поэтому там нет аутентификации, не надо отдельно следить за безопасностью этих прокси. На своей рабочей машине под Windows открываю WSL, там подключаюсь по SSH примерно так:
# ssh -L 192.168.99.2:3128:localhost:8118 root@1.2.3.4или так:
# ssh -D 192.168.99.2:3128 root@4.3.2.1где 1.2.3.4 и 4.3.2.1 - IP VDS, а 192.168.99.2 - IP адрес внутри WSL. В браузере в качестве прокси указываю 192.168.99.2, порт 3128. В зависимости от подключенной VPS, работает та или иная локация для доступа в интернет.
Для сёрфинга или загрузки чего-либо мне такая схема кажется наиболее простой, безопасной и удобной в качестве обслуживания. Наружу торчат только SSH порты, что безопасно. Не привлекают к себе лишнего внимания, в отличие от открытых портов прокси. При этом я имею возможность подключаться к ним откуда угодно. И не нужно использовать VPN, которые иногда могут не работать.
В SwitchyOmega можно создавать разные профили настроек, переключаться между ними вручную или автоматически.
#ssh #proxy
Иногда бывают ситуации, когда надо перекинуть файлы с одного сервера на другой, но при этом прямого доступа по ssh между этими серверами нет, не настроена аутентификация. Но вы при этом можете подключиться по ssh к каждому из этих серверов. Вариантов решения задачи как минимум два:
1️⃣ Скопировать файлы с одного сервера сначала к себе, а потом от себя на второй сервер. Я летом часто работаю по 4G, мне такой вариант не подходит. Как подвариант этого же варианта, копировать файлы на какой-то промежуточный сервер со скоростным интернетом.
2️⃣ Настроить аутентификацию между двумя серверами. Иногда это не хочется делать, а когда-то и невозможно. Для этого понадобится либо лишние сертификаты создавать, которые могут быть запаролены, либо включать аутентификацию по паролю. Я лично не против последнего, но часто её отключают.
Выйти из этой ситуации можно относительно просто без лишних телодвижений на серверах. На помощь придёт ssh-agent, который входит в состав ssh-client. Отдельно ставить не надо. Если его просто запустить, то он выведет свои переменные в терминал:
Нам нужно их загрузить в оболочку для последующего использования. Сделаем это так:
Проверяем переменные:
Теперь добавим свои ключи из ~/.ssh в ssh-agent:
Посмотреть все добавленные ключи можно командой:
Почти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл
Всё, теперь можно подключаться:
Вы должны подключиться к серверу с пробросом агента. Проверьте это, зайдя в
Теперь если вы куда-то будете подключаться по ssh с этого сервера, будет использоваться проброшенный ключ с вашей машины. То есть вы можете выполнить что-то вроде этого:
Данные с сервера 1.2.3.4 будут скопированы на сервер 5.6.7.8 с использованием сертификата с вашей рабочей машины. Прямой аутентификации с 1.2.3.4 на 5.6.7.8 настроено не будет.
Простой трюк, который можно использовать не только для копирования файлов. Подобную цепочку можно делать бесконечно длинной, но нужно понимать, что если вы захотите с сервера 5.6.7.8 подключиться куда-то дальше с этим же сертификатом, вам нужно будет на 1.2.3.4 так же настраивать проброс агента.
Тут важно понимать один момент, связанный с безопасностью. Когда вы подключились к какому-то серверу с пробросом агента, root пользователь этого сервера тоже получает доступ к этому агенту и может его использовать по своему усмотрению. Так что аккуратнее с этим. На чужие сервера на всякий случай так не ходите. И не включайте проброс агента по умолчанию для всех серверов и соединений. Когда он не нужен, отключайте.
#ssh
1️⃣ Скопировать файлы с одного сервера сначала к себе, а потом от себя на второй сервер. Я летом часто работаю по 4G, мне такой вариант не подходит. Как подвариант этого же варианта, копировать файлы на какой-то промежуточный сервер со скоростным интернетом.
2️⃣ Настроить аутентификацию между двумя серверами. Иногда это не хочется делать, а когда-то и невозможно. Для этого понадобится либо лишние сертификаты создавать, которые могут быть запаролены, либо включать аутентификацию по паролю. Я лично не против последнего, но часто её отключают.
Выйти из этой ситуации можно относительно просто без лишних телодвижений на серверах. На помощь придёт ssh-agent, который входит в состав ssh-client. Отдельно ставить не надо. Если его просто запустить, то он выведет свои переменные в терминал:
# ssh-agentSSH_AUTH_SOCK=/tmp/ssh-XXXXXXm7P5A8/agent.259; export SSH_AUTH_SOCK;SSH_AGENT_PID=260; export SSH_AGENT_PID;echo Agent pid 260;Нам нужно их загрузить в оболочку для последующего использования. Сделаем это так:
# eval `ssh-agent`Agent pid 266Проверяем переменные:
# env | grep SSH_SSH_AUTH_SOCK=/tmp/ssh-XXXXXXrrbmpN/agent.265SSH_AGENT_PID=266Теперь добавим свои ключи из ~/.ssh в ssh-agent:
# ssh-addПосмотреть все добавленные ключи можно командой:
# ssh-add -lПочти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл
~/.ssh/config параметр для каждого сервера, к которому будем подключаться. Сервер можно указать как по ip адресу, так и по имени, в зависимости от того, как вы будете подключаться:Host 1.2.3.4 ForwardAgent yesHost srv-01 ForwardAgent yesВсё, теперь можно подключаться:
# ssh root@1.2.3.4Вы должны подключиться к серверу с пробросом агента. Проверьте это, зайдя в
/tmp подключенного сервера. Там должен быть сокет агента:root@1.2.3.4# ls /tmp | grep ssh-ssh-vSnzLCX7LWТеперь если вы куда-то будете подключаться по ssh с этого сервера, будет использоваться проброшенный ключ с вашей машины. То есть вы можете выполнить что-то вроде этого:
root@1.2.3.4# rsync -av /var/www/ root@5.6.7.8:/var/www/Данные с сервера 1.2.3.4 будут скопированы на сервер 5.6.7.8 с использованием сертификата с вашей рабочей машины. Прямой аутентификации с 1.2.3.4 на 5.6.7.8 настроено не будет.
Простой трюк, который можно использовать не только для копирования файлов. Подобную цепочку можно делать бесконечно длинной, но нужно понимать, что если вы захотите с сервера 5.6.7.8 подключиться куда-то дальше с этим же сертификатом, вам нужно будет на 1.2.3.4 так же настраивать проброс агента.
Тут важно понимать один момент, связанный с безопасностью. Когда вы подключились к какому-то серверу с пробросом агента, root пользователь этого сервера тоже получает доступ к этому агенту и может его использовать по своему усмотрению. Так что аккуратнее с этим. На чужие сервера на всякий случай так не ходите. И не включайте проброс агента по умолчанию для всех серверов и соединений. Когда он не нужен, отключайте.
#ssh
Нашёл очень функциональный инструмент для логирования действий пользователей в подключениях по SSH к серверам. Речь пойдёт про open sourse проект sshlog. Выглядит он так, как-будто хотели сделать на его основе коммерческий продукт, но в какой-то момент передумали и забросили. Сделан он добротно и целостно. Расскажу по порядку.
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
Установить sshlog можно из репозитория разработчиков:
Репозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
-
-
В директории
Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
sudo su. В описании нигде этого не сказано, но я сам на практике убедился. Плюс, увидел такие же комментарии в вопросах репозитория. Установить sshlog можно из репозитория разработчиков:
# curl https://repo.sshlog.com/sshlog-ubuntu/public.gpg | gpg --yes --dearmor -o /usr/share/keyrings/repo-sshlog-ubuntu.gpg# echo "deb [arch=any signed-by=/usr/share/keyrings/repo-sshlog-ubuntu.gpg] https://repo.sshlog.com/sshlog-ubuntu/ stable main" > /etc/apt/sources.list.d/repo-sshlog-ubuntu.list# apt update && apt install sshlogРепозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
/etc/sshlog/conf.d будут 2 файла конфигурации:-
log_all_sessions.yaml - запись ssh сессий в директорию /var/log/sshlog/sessions, каждая сессия в отдельном лог файле, сохраняется в том числе вывод в консоли, а не только введённые команды.-
log_events.yaml - запись событий: подключения, отключения, введённые команды, общий лог для всех.В директории
/etc/sshlog/samples будут примеры некоторых других настроек. Вся конфигурация в формате yaml, читается легко, интуитивно. Возможности программы большие. Можно логировать только какие-то конкретные события. Например, запуск sudo. Либо команды от отдельного пользователя. Это можно настроить либо в событиях, либо в исключениях. Подробно механизм описан отдельно: sshlog config.Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
