Хочу подкинуть вам идею, которая может когда-нибудь пригодиться. Подключение к NFS серверу можно организовать через проброс портов по SSH и это нормально работает. Когда есть sshfs, может показаться, что в этом нет никакого смысла. Могу привести свой пример, когда мне это пригодилось.

Мне нужно было перекинуть бэкапы виртуалок с внешнего сервера 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

​​Очень простой и быстрый способ настроить уведомления об успешном SSH подключении к серверу в Telegram. Для этого понадобится свой bot, простенький bash скрипт и изменение конфига PAM для SSH. Будем через него уведомления делать.

Рассказывать про создание бота не буду. Надо создать нового бота, получить его токен. Также понадобится ваш ID. Узнать можно разными способами, например через бота @my_id_bot.

Далее берём простой скрипт:

#!/bin/bash

if [ "$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/null
fi

Тут мы проверяем переменную 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.sh
session  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. Это бесплатная программа, которая есть в стандартных репозиториях популярных дистрибутивов.

# apt install autossh

Autossh отслеживает 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 Tunnel
After=network-online.target

[Service]
Type=forking
User=userssh
ExecStart=/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.1
ExecStop=/usr/bin/pkill -9 -u userssh
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target

Запускаем и добавляем в автозагрузку:

# systemctl daemon-reload
# systemctl start autossh.service
# systemctl enable autossh.service

Проверяем на внешнем сервере:
# netstat -tulnp | grep 9033
tcp    0   0 127.0.0.1:9033     0.0.0.0:*        LISTEN   19814/sshd: userssh
tcp6    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

​​Смотрите, какая прикольна штука есть для подключения по SSH из консоли - sshto. Это небольшой bash скрипт, который позволяет через псевдографическое меню управлять преднастроенными SSH подключениями. Хорошее решение для самодельного jumphost.

Это когда вы используете промежуточный сервер для подключения к целевым серверам. Такой подход позволяет гибко управлять доступом на основе пользователей jump севера, логировать команды и записывать вывод консоли. И всё без каких-то специализированных решений. В основном средствами самого Linux и его небольших утилит. У меня в разное время были различные заметки по этой теме. Если интересно, могу собрать их в одну.

Вернёмся к sshto. Как я уже сказал, это bash скрипт, который читает конфигурацию из файла ~/.ssh/config и выводит список серверов оттуда в псевдографическое меню. Вот пример такого файла:

#Host DUMMY #Moscow#

Host server-number-one #First Server
HostName 1.2.3.4
port 22777
user root

Host server-number-two #Second server
HostName 4.3.2.1
port 22888
user username

#Host DUMMY #Saint Petersburg#

Host server-number-three #Third server
HostName 5.6.7.8
port 22
user user01

Host server-number-four #Fourth server
HostName 9.8.7.6
port 22
user user02

Ставим sshto:
# git clone https://github.com/vaniacer/sshto
# cd sshto/
# cp sshto /usr/bin/
Запускаем:
# sshto

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

#ssh #bash #script

​​Я по привычке всегда создаю ключи для SSH с использованием протокола RSA. Просто добавляю параметр для длины ключа 4096. Когда-то увидел информацию, что меньшая длина теоретически может быть небезопасной.

# 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:

# 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, создаёт виртуалку и запускает. Весь процесс автоматизирован. По этой теме имеет смысл сделать отдельную публикацию с описанием. Очень интересное решение получилось. Я пока только посмотрел, сам не пробовал запускать.

Если посмотрите видео, то не забудьте зайти в комментарии и поблагодарить авторов. Вам это ничего не стоит, а им приятно.

#видео

​​Расскажу вам про один любопытный инструмент, который часто используют либо пентестеры, либо хакеры, чтобы закрепиться в чужой инфраструктуре. А так как это всё напрямую связано с системным администрированием, то инструмент может пригодиться и в обычных делах. Благо он очень простой для использования и освоения, поэтому относительно популярный. По нему много информации в англоязычном интернете.

Речь пойдёт про 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:

# apt install privoxy

Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.

Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb
HTTP request sent, awaiting response... 403 Forbidden

Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:

# ssh -L 3128:localhost:8118 root@1.2.3.4

Проверяем, что порт проброшен:

# ss -tulnp | grep 3128
tcp  LISTEN 0   128    127.0.0.1:3128    0.0.0.0:*  users:(("ssh",pid=1350,fd=5))

Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:

use_proxy=yes
http_proxy=127.0.0.1:3128
https_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 docker
Environment=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 примерно так:

# 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-agent
SSH_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.265
SSH_AGENT_PID=266

Теперь добавим свои ключи из ~/.ssh в ssh-agent:

# ssh-add

Посмотреть все добавленные ключи можно командой:

# ssh-add -l

Почти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл ~/.ssh/config параметр для каждого сервера, к которому будем подключаться. Сервер можно указать как по ip адресу, так и по имени, в зависимости от того, как вы будете подключаться:

Host 1.2.3.4
ForwardAgent yes

Host 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 нельзя. Только обычных пользователей, даже если они сделают 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