​​Ранее я уже рассказывал о полезных возможностях ssh. Речь была о SOCKS-прокси и переадресации портов через ssh. Сейчас расскажу о том, как настроить полноценный vpn туннель с помощью подключения по ssh.

Сразу отвечу на вопрос, зачем это вообще нужно, если есть куча других способов настроить vpn. Все дело в простоте и времени настройки. Обычно на сервере уже есть настроенный openssh сервер, так что ничего дополнительно устанавливать не надо. Берёте любой линукс сервер или виртуальную машину и организовываете через него vpn канал.

Для начала вам нужно включить параметр в конфиге /etc/ssh/sshd_config:
PermitTunnel yes
и перезапустить службу sshd.

Далее с клиента подключаетесь к серверу по ssh со следующими ключами:
ssh -p 22777 -w3:3 root@111.222.333.444

w3:3 - имена tun интерфейсов, которые будут созданы на клиенте и сервере (в данном случае tun3). Обращаю внимание, что подобное подключение напрямую из Windows работать не будет. Я для этого подключаюсь через WSL.

После подобного ssh подключения, на сервере и клиенте поднимаются tun3 интерфейсы и фактически vpn канал уже создан. Дальше вам нужно вручную назначить им ip адреса и можно передавать информацию по зашифрованному vpn каналу поверх ssh подключения. Что-то вроде этого надо сделать:
server: ip a add 10.20.0.1/30 dev tun3
server: ip link set dev tun3 up
client: ip a add 10.20.0.2/30 dev tun3
client: ip link set dev tun3 up

Я взял подсеть 10.20.30.0 с маской 30, где всего 2 ip адреса и объединил клиента и сервера в рамках это подсети. Теперь можно пинговать по этим адресам друг друга с сервера или клиента.

Дальше есть разные варианты, как использовать это подключение. Если вы с клиента захотите увидеть локальную сеть за сервером, то на самом сервере нужно будет настроить ip_forward и nat для tun интерфейса, а на клиенте добавить маршрут в эту локалку через vpn канал. Всё точно так же, как и на других vpn туннелях.

Если тема заинтересовала без проблем нагуглите пошаговую инструкцию. Я просто дал информацию о том, что так можно сделать. Как-то объединял по быстрому два филиала через такой туннель. Автоматизировал всё через обычные bash скрипты. Один сервер стоял на базе какой-то готовой сборки с веб панелью управления. И всё это дремучей версии, непонятно кем и как настроенный. Я не захотел туда лазить, разбираться и что-то ставить дополнительно. Просто настроил vpn поверх ssh и закрыл вопрос.

#ssh #vpn

Есть небольшая утилита для организации vpn подключения через ssh - sshuttle. Она есть в стандартных репозиториях популярных дистрибутивов. В Centos живет в репозитории epel. Также присутствует в pip, так как написана на python.

https://github.com/sshuttle/sshuttle
https://sshuttle.readthedocs.io/en/stable/usage.html

Установка:
# 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

​​Нередко возникает задача по логированию действий пользователя на сервере. Я нагуглил простое и эффективное решение - log-user-session. Проблема возникла одна - никакого описания, как это настраивается. Даже примера конфига нет в репозитории, хотя в описании упомянуто, что он может существовать.

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

Проверял всё на 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

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