​​Я как-то раз уже вскользь упоминал о возможности пробрасывать порты через 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.

Копируем репозитоий:
# 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 перед самим сертификатом добавляем разрешённую команду:
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 на внешний сервер:

# 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

Я уже как-то рассказывал про утилиту sshfs, которая позволяет монтировать удалённую файловую систему через SSH. То есть просто монтируете сетевой диск, используя только SSH соединение. Это не очень быстро, так как подключение выполняется в пространстве пользователя, да и в целом по SSH не очень быстрые соединения. Но для некоторых задач это бывает удобно. Доступ по SSH есть практически всегда.

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

Ставим sshfs:

# apt install sshfs

Генерируем и копируем на удалённую машину ключ:

# ssh-keygen -t ed25519
# ssh-copy-id root@10.20.1.6

Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.

Всё готово, монтируем д иректорию /etc/letsencrypt с сервера 10.20.1.6 к себе в /mnt/letsencrypt:

# sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt

Проверяем:

# df -h | grep 10.20.1.6
root@10.20.1.6:/etc/letsencrypt  20G 1.8G  17G 10% /mnt/letsencrypt

Размонтировать можно вот так:

# fusermount -u /mnt/letsencrypt

Создаём службу systemd:

# systemctl edit --force --full sshfs.service

[Unit]
Description=Mount sshfs
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt
ExecStop=fusermount -u /mnt/letsencrypt

[Install]
WantedBy=multi-user.target

Сохраняем, запускаем, добавляем в автозагрузку:

# systemctl start sshfs.service
# systemctl enable sshfs.service

Если хотим отмонтировать, то просто останавливаем:

# systemctl stop sshfs.service

Я показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры

User=sftp-user
Group=sftp-user

Можно в systemd указать пользователя, под которым всё это будет монтироваться.

Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ssh #fileserver

В разное время на канале выходили публикации на тему логирования действий пользователя в терминале, в частности при подключениях по SSH. Тема востребованная, актуальная, так что решил все заметки по ней собрать в одном месте. К тому же решения предлагались очень сильно разные. Будет полезно их увидеть и сравнить в одном месте, от самых простых, до больших корпоративных систем.

◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.

◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.

◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду history 1, которая показывает последнюю введённую команду и куда-то записываем её: в файл или syslog. Решение максимально простое и понятное, но со своими нюансами. Надо промты менять и следить, чтобы обратно не менялись.

◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.

◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.

◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ssh #logs #подборка