🛡️ Аудит безопасности — vipnet

Узел ViPNet · FTP-шлюз в ЕГИС ОТБ · АРМ
Дата аудита: 2026-06-06
Хост: vm-evrotrans-yandex-vipnet-1769183391910
ОС: Ubuntu 20.04.6 LTS · ядро 5.4.0-216
Платформа: Yandex Cloud
Сеть: ViPNet tun0 7.1.39.7 · VPC 10.128.0.0/24
Uptime: 133 дня
Источник: ручной аудит из-под root (audit.sh)
См. также: архитектура узла · общая карта

1. Сводка

4
🔴 Высокая критичность
7
🟠 Средняя критичность
7
🟢 Настроено хорошо
КритичностьТемы
🔴 ВысокаяNOPASSWD-sudo у orphan-аккаунта y4tsun0v, firewall выключен, открытый незашифрованный FTP (vsftpd + ftp-proxy), лишний десктоп-стек (LightDM/Xorg/VNC/CUPS/Avahi) на сервере
🟠 СредняяЧлены группы docker = root-эквивалент, %google-sudoers NOPASSWD, Zabbix/Acronis на всех интерфейсах, mDNS/CUPS-broadcast в сеть, пароли без срока, X11Forwarding yes, образы FTP-стека 4 месяца без пересборки
🟢 ХорошоSSH: запрет root, только ключи, AllowUsers, нестандартный порт, MaxAuthTries 3; вход только из внутренней сети; нет публичного брутфорса; контейнеры непривилегированные; root-пароль заблокирован; .env без секретов; один UID 0
Главный вывод: SSH настроен так же грамотно, как на первом сервере, и доступ идёт только из внутренней сети (10.128.0.0/24 через ViPNet) — это плюс. Но у этого узла гораздо шире локальная поверхность атаки: полноценное графическое окружение с VNC, печатью и mDNS-вещанием, отключённый firewall и открытый FTP в открытом виде. Плюс повторяется проблема первого сервера — orphan-аккаунт y4tsun0v с беспарольным root.
Содержание
  1. Учётные записи и привилегии
  2. SSH
  3. Приватные ключи и секреты на диске
  4. Запущенные сервисы
  5. Сетевые порты
  6. Активность входов
  7. Cron / timers
  8. Firewall
  9. Docker (FTP-стек)
  10. SUID/SGID
  11. Незавершённые проверки
  12. План действий
  13. Что хорошо
  14. Сравнение серверов

2. Учётные записи и привилегии

2.1 Интерактивные пользователи

ПользовательUIDОболочкаПарольSSH-входsudo / dockerНазначение
root0/bin/bash🔒 L (заблокирован)❌ запрещёнСистемный
y4tsun0v1000/bin/bash✅ P (задан)❌ нет в AllowUsers🔴 NOPASSWD:ALLOrphan от первичной настройки VM
r3ddan91001/bin/bash✅ P✅ разрешёнsudo (с паролем) + 🟠 dockerАдминистратор (danil)
evrotrans1002/bin/bash✅ P✅ разрешён🟠 docker (root-эквивалент)Сервисный/прикладной аккаунт

UID 0 ровно один (root) — скрытых суперпользователей нет ✅ · Пустых паролей нет ✅

2.2 🔴/🟠 sudo и группа docker — детально

root            ALL=(ALL:ALL) ALL              # /etc/sudoers
%admin          ALL=(ALL) ALL                  # группа admin — ПУСТАЯ
%sudo           ALL=(ALL:ALL) ALL              # группа sudo — только r3ddan9
y4tsun0v        ALL=(ALL) NOPASSWD:ALL         # /etc/sudoers.d/90-cloud-init-users 🔴
%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL     # /etc/sudoers.d/google_sudoers 🟠
🔴 y4tsun0v имеет полный root БЕЗ пароля через cloud-init drop-in. Зайти по SSH он не может (нет в AllowUsers), но любой, кто получит локальную сессию под этим пользователем (через su/cron/эксплойт сервиса/локальную консоль десктопа), сразу становится root без пароля. Это та же проблема, что и на первом сервере.
🟠 Группа docker = root без пароля. И r3ddan9, и evrotrans состоят в группе docker. Любой член этой группы может смонтировать / в контейнер и получить полный root (docker run -v /:/host ...). Для evrotrans (сервисный аккаунт без sudo) это фактически обходной путь к root в обход политики паролей.

🟠 %google-sudoers NOPASSWD:ALL — стандартный механизм Yandex Cloud: пользователи, попавшие в эту группу через метаданные/OS Login проекта, получают беспарольный root. Это альтернативный канал привилегий, управляемый из облачной консоли.
🔍 Доказательство — cat /etc/sudoers.d/90-cloud-init-users
# sudo cat /etc/sudoers.d/90-cloud-init-users
y4tsun0v ALL=(ALL) NOPASSWD:ALL
# orphan-аккаунт y4tsun0v получает полный root без пароля
🔍 Доказательство — cat /etc/sudoers.d/google_sudoers
# sudo cat /etc/sudoers.d/google_sudoers
%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL
# любой член группы google-sudoers (из метаданных Yandex Cloud) — беспарольный root
🔍 Доказательство — getent group docker
# getent group docker
docker:x:998:r3ddan9,evrotrans
# член группы docker монтирует / в контейнер → root-эквивалент
🔍 Доказательство — getent group sudo / admin
# getent group sudo
sudo:x:27:r3ddan9
# getent group admin
# группа admin — пустая (вывода нет)

2.3 Политика паролей

PASS_MAX_DAYS   99999   # пароли НИКОГДА не истекают ⚠️
PASS_MIN_DAYS   0
PASS_WARN_AGE   7

🟠 Пароли бессрочные. Влияет на локальный вход / su / графическую консоль (LightDM).

3. SSH — конфигурация и доступ

3.1 Настройки демона (sshd -T)

ПараметрЗначениеОценка
port48008 (нестандартный)
permitrootloginno
passwordauthenticationno✅ только ключи
pubkeyauthenticationyes
permitemptypasswordsno
maxauthtries3
allowusersr3ddan9 evrotrans✅ белый список
x11forwardingyes🟠 без необходимости расширяет поверхность
🔍 Доказательство — sshd -T
# sudo sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding|allowusers)'
port 48008
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
maxauthtries 3
x11forwarding yes
allowusers r3ddan9 evrotrans
# только ключи, root запрещён, белый список — но x11forwarding лишний

Итог: конфигурация SSH соответствует лучшим практикам. Единственная придирка — X11Forwarding yes (на этом узле есть GUI, но проброс X11 по SSH обычно не нужен — лучше no).

3.2 Авторизованные ключи (authorized_keys)

ФайлКлючиКомментарий
/root/.ssh/authorized_keysdanil@IdeaPad-3-14ALC6⚠️ С форсированной командой-заглушкой (command="echo 'Please login as ...'") — вход под root заблокирован. ✅ Хорошая практика.
/home/y4tsun0v/.ssh/authorized_keysdanil@IdeaPad-3-14ALC6 («Added by Google»)Тот же личный ключ
🟠 Тот же переиспользуемый ключ. Личный ключ danil@IdeaPad-3-14ALC6 (один и тот же, что и на первом сервере!) прописан у root (заглушка) и у y4tsun0v. Компрометация этого приватного ключа на ноутбуке IdeaPad-3-14ALC6 = доступ сразу к обоим серверам.
⚠️ Незавершённая проверка: в выводе аудита есть authorized_keys только для root и y4tsun0v, хотя в AllowUsers указаны r3ddan9 и evrotrans. Их ключи, вероятно, инжектируются google-guest-agent из метаданных Yandex Cloud (механизм google_authorized_keys) и не попали в выборку. Нужно перепроверить ключи r3ddan9/evrotrans и метаданные проекта (см. §12).
🔍 Доказательство — cat .../authorized_keys
# sudo cat /root/.ssh/authorized_keys /home/y4tsun0v/.ssh/authorized_keys
command="echo 'Please login as ...'" ssh-rsa AAAA... danil@IdeaPad-3-14ALC6
ssh-rsa AAAA... danil@IdeaPad-3-14ALC6
# оба — один ключ danil@IdeaPad-3-14ALC6 (у root с командой-заглушкой);
# ключи r3ddan9/evrotrans в выводе отсутствуют — вероятно из метаданных Yandex Cloud, перепроверить

4. Приватные ключи и секреты на диске

На этом узле, в отличие от первого, прикладных приватных ключей в дереве приложения почти нет. Большинство найденного — штатные системные файлы. Ниже разделено на значимое и шум.

4.1 🟠 Заслуживают внимания

ПутьЧто этоРиск
/home/evrotrans/.vnc/...-SrvKey.pem + ...-SrvCert.pemПриватный ключ и сертификат сервера VNC (TigerVNC)🟢 Уточнено: VNC не запущен, systemd-юнита нет. По логам слушал только localhost:5903, пароль задан (~/.vnc/passwd, права 600). Доступ возможен лишь через SSH-туннель — риск низкий.
/home/evrotrans/.vipnet/.../for_rand.key (×2)Файлы инициализации ГПСЧ ViPNet CSP🟠 Часть криптоядра ViPNet. Должны быть с правами 600 и недоступны другим пользователям. Не «секрет приложения», но компонент сертифицированной криптозащиты.
./ftp-*/config/*.confКонфиги ftp-proxy с адресами upstream-серверов🟠 Монтируются в контейнеры :ro. Содержат адреса/учётки вышестоящих FTP (цели — *.import.inet.egis-otb.local:21021).
/home/evrotrans/stable/.env проверен — секретов нет (только TZ/ENV_TIMEZONE/DOCKER_CONTENT_TRUST=1).
🔍 Доказательство — cat /home/evrotrans/stable/.env
# cat /home/evrotrans/stable/.env
TZ="Europe/Moscow"
ENV_TIMEZONE="Europe/Moscow"
DOCKER_CONTENT_TRUST=1
# паролей/токенов нет ✅
🔍 Доказательство — cat .vnc/*.log (состояние VNC)
# ss -tlpn | grep -E ':590[0-9]'
# вывод пуст — VNC сейчас не слушает
# из ~/.vnc/*.log:
Listening for VNC connections on 127.0.0.1 port 5903
# слушал только localhost:5903 → доступ возможен лишь через SSH-туннель
🔍 Доказательство — cat ./ftp-*/config/*.conf
# cat /home/evrotrans/stable/ftp-*/config/*.conf
DestinationAddress auto.pdp.import.inet.egis-otb.local
DestinationAddress auto.onsi.import.inet.egis-otb.local
DestinationAddress auto.timetable.import.inet.egis-otb.local
DestinationAddress auto.ack.import.inet.egis-otb.local
DestinationPort 21021
User nobody
# цели прокси — ЕГИС ОТБ, монтируются в контейнеры :ro, прокси под nobody

4.2 ⚪ Штатные системные файлы (не риск)

5. Запущенные сервисы

systemctl — значимое и нетипичное для сервера:

СервисНазначениеПримечание
ssh.serviceOpenSSHпорт 48008 ✅
docker / containerdDocker4 FTP-контейнера (см. §10)
vsftpd.serviceFTP-сервер🔴 порт 48080 + ftp-proxy 21001–21004, см. §6
lightdm.serviceГрафический менеджер входа (X11)🔴 Десктоп-окружение на сервере
cups.service / cups-browsedСистема печати + автообнаружение принтеров🟠 Не нужна на сервере; cups-browsed вещает в сеть
avahi-daemon.servicemDNS/Zeroconf🟠 Вещает имя/сервисы по сети (5353/udp)
colord / switcheroo-control / upower / rtkit-daemon / udisks2Десктоп-демоны (цвет, GPU, питание, аудио, диски)🟠 Атрибуты рабочей станции, не сервера
(TigerVNC)Удалённый рабочий столключ есть, порт сейчас не слушается ✅
zabbix-agent2.serviceМониторингпорт 10050 на всех интерфейсах 🟠
aakore / acronis_mms / acronis_schedule / active-protection / acp-update-controllerAcronis Cyber Protectlocalhost + grpm-sync на всех интерфейсах 🟠
vipnetclientdaemon (timer/демон)Клиент ViPNettun0 7.1.39.7, udp 41034/55781, dns на 7.1.39.7:53
google-guest-agent.serviceYandex Cloud гостевой агентуправляет SSH-ключами/sudo через метаданные (см. §3.2, §12)
unattended-upgrades.serviceАвтообновления безопасности
🔴 Десктоп-стек на сервере. LightDM/Xorg, CUPS, Avahi, colord, upower, switcheroo, rtkit — это набор рабочей станции. Каждый из них — лишний код с историей уязвимостей и сетевым вещанием. Если графика реально нужна для работы с ViPNet/АРМ — это объяснимо, но тогда узел стоит трактовать как рабочую станцию, а не сервер, и соответственно изолировать.
🔍 Доказательство — systemctl list-units (десктоп-стек)
# systemctl list-units --type=service --state=running | grep -E 'lightdm|cups|avahi|colord|switcheroo|rtkit'
lightdm.service
cups.service
cups-browsed.service
avahi-daemon.service
colord.service
switcheroo-control.service
rtkit-daemon.service
# набор рабочей станции на сервере — лишняя поверхность атаки
⚠️ google-guest-agent может автоматически добавлять SSH-ключи/пользователей и членство в google-sudoers из метаданных проекта. Контроль над метаданными в облаке = контроль над доступом к VM.

6. Сетевые порты (ss -tulpn)

6.1 Доступны извне (0.0.0.0 / * / [::])

ПортПротоколПроцессОценка
48008tcpsshd✅ SSH (ключи)
48080tcpvsftpd🔴 FTP, ssl_enable=NO — открытый текст, вход локальных юзеров
21001–21004tcpftp-proxy (контейнеры)🔴 FTP-прокси к контрагентам через ViPNet, на 0.0.0.0
10050tcp (*)zabbix_agent2🟠 Должен видеть только сервер Zabbix
41765tcp (*)grpm-sync-unit (Acronis)🟠 Слушает на всех интерфейсах
5353 / 38317 / 39398udpavahi-daemon🟠 mDNS-вещание в сеть
41034 / 55781udpvipnetclientViPNet (ожидаемо) ✅

6.2 Только localhost (127.0.0.1 / ::1) — ✅ безопасно

53 (resolved), 631 (CUPS — слушает только localhost ✅), 33159 (task-manager), 35375 (aakore), 43234/9850 (Acronis mms), 6109 (active-protection), 9772 (adp-agent), 24100–24102 (mms udp).

🔍 Доказательство — ss -tulpn
# ss -tulpn
tcp LISTEN 0.0.0.0:48008        users:(("sshd",...))
tcp LISTEN 0.0.0.0:48080        users:(("vsftpd",...))
tcp LISTEN 0.0.0.0:21001        users:(("ftp-proxy",...))
tcp LISTEN 0.0.0.0:21002        users:(("ftp-proxy",...))
tcp LISTEN 0.0.0.0:21003        users:(("ftp-proxy",...))
tcp LISTEN 0.0.0.0:21004        users:(("ftp-proxy",...))
tcp LISTEN *:10050              users:(("zabbix_agent2",...))
tcp LISTEN *:41765              users:(("grpm-sync-unit",...))
udp UNCONN *:5353               users:(("avahi-daemon",...))
udp UNCONN *:41034              users:(("vipnetclient",...))
udp UNCONN *:55781              users:(("vipnetclient",...))
tcp LISTEN 127.0.0.1:631        users:(("cupsd",...))
# FTP/Zabbix/Acronis/Avahi на 0.0.0.0; CUPS (631) — только localhost ✅
🔴 FTP (vsftpd 48080): подтверждено по /etc/vsftpd.confssl_enable=NO, логины/пароли и файлы идут открытым текстом. Пускает в свой $HOME (chroot) только r3ddan9 и evrotrans (/etc/vsftpd.userlist). Это те же учётки, что и для SSH/sudo/docker — то есть по открытому FTP по сети ходит пароль администратора и оператора узла; перехват = доступ к привилегированным аккаунтам.

Действие: включить FTPS (ssl_enable=YES, нормальный сертификат) или перейти на SFTP; ограничить источники firewall'ом.
🔍 Доказательство — grep ... /etc/vsftpd.conf
# grep -E 'ssl_enable|listen_port|userlist' /etc/vsftpd.conf
listen_port=48080
ssl_enable=NO
userlist_enable=YES
userlist_deny=NO
# cat /etc/vsftpd.userlist
r3ddan9
evrotrans
# ssl_enable=NO → пароли привилегированных учёток идут открытым текстом
🔴 ftp-proxy (21001–21004): четыре прокси ftp-proxy (proxy-suite, под nobody ✅) на 0.0.0.0. Проксируют FTP в ЕГИС ОТБ{pdp,onsi,timetable,ack}.import.inet.egis-otb.local:21021 через ViPNet (карта сетей — в ARCHITECTURE §2.3, поток данных — §9). Сам FTP незашифрован, но канал защищён ViPNet; ограничить источники подключения к прокси firewall'ом.
🔍 Доказательство — ss -tlpn | grep '2100[1-4]'
# ss -tlpn | grep -E '2100[1-4]'
LISTEN 0.0.0.0:21001  users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21002  users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21003  users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21004  users:(("ftp-proxy",...))
# четыре прокси к ЕГИС ОТБ слушают на всех интерфейсах (0.0.0.0)
🟠 Zabbix (10050), Acronis grpm-sync (41765), Avahi (5353) слушают все интерфейсы — ограничить firewall'ом доверенными IP. Avahi на серверном узле лучше выключить.

CUPS (631) слушает только localhost — хорошо (печать не выставлена в сеть), хотя сам сервис на сервере избыточен.

7. Активность входов

7.1 Текущие/недавние сессии (who, last)

7.2 Неудачные входы (lastb)

🔍 Доказательство — last / lastb
# last | head
r3ddan9   pts/0   10.128.0.20   ...still logged in
r3ddan9   pts/0   10.128.0.20   ...
evrotrans pts/1   10.128.0.15   ...
# все входы — только из внутренней сети 10.128.0.x
# sudo lastb | head
... 10.128.0.15 ...
# почти пусто (2 попытки с 10.128.0.15) — публичного брутфорса нет ✅

8. Задачи по расписанию (cron / timers) — ✅ в норме

9. Firewall и сетевая фильтрация — 🔴 выключен

ufw Status: inactive
iptables -S: -P INPUT ACCEPT / -P FORWARD DROP / -P OUTPUT ACCEPT
            (только авто-цепочки DOCKER/DOCKER-ISOLATION/DOCKER-USER)
🔴 Локальный firewall выключен. Политика INPUT ACCEPT, никаких пользовательских правил — фильтрации входящего трафика на хосте нет вообще. Всё, что слушает на 0.0.0.0 (FTP, Zabbix, Acronis, Avahi), доступно с любого узла, который дотянется по сети. Единственная защита сейчас — облачные security-groups Yandex Cloud и периметр ViPNet (их состояние из этого аудита не видно).

Действие: включить ufw/nftables с дефолтным deny incoming, явно разрешить только нужное (SSH 48008, FTP-порты — с доверенных подсетей, Zabbix/Acronis — с IP мониторинга). И/или убедиться, что облачные security-groups жёстко ограничивают вход.

10. Docker (FTP-стек)

По docker-compose.yml + docker inspect. Это не FTP-серверы, а прокси ftp-proxy (proxy-suite, /usr/sbin/ftp-proxy -n -d). Compose-проект stable, образы на базе ubuntu:20.04.

СервисКонтейнерПортПривилегии
ftp-pdpstable-ftp-pdp-121001priv=false, сокет не проброшен ✅
ftp-onsistable-ftp-onsi-121002
ftp-timetablestable-ftp-timetable-121003
ftp-ackstable-ftp-ack-121004
Хороший хардненинг прикладного стека:
Замечания:

11. SUID/SGID (хост)

Список штатный — аномалий нет ✅: sudo, su, mount/umount, passwd, chsh/chfn, gpasswd, newgrp, pkexec, fusermount, at, crontab, ssh-keysign, ssh-agent, chage/expiry, pppd (группа dip), а также десктоп-хелперы Xorg.wrap, dbus-daemon-launch-helper, polkit-agent-helper-1, mc/cons.saver.

12. Незавершённые проверки (повторить)

ПроверкаЧто сделатьКоманда
Ключи r3ddan9/evrotransВ выводе только root и y4tsun0v; проверить реальные authorized_keys админов и сервисного аккаунтаfor u in r3ddan9 evrotrans; do echo "== $u =="; cat /home/$u/.ssh/authorized_keys; done
Метаданные Yandex Cloud / OS LoginАльтернативный канал доступа в обход authorized_keysпроверить enable-oslogin, ключи проекта/инстанса в облачной консоли
.env приложенияПроверено — секретов нет (TZ/DOCKER_CONTENT_TRUST=1)
Конфиги ftp-proxyЦели — *.import.inet.egis-otb.local:21021 (ЕГИС ОТБ), прокси под nobody
/etc/vsftpd.userlistТолько r3ddan9, evrotrans
Роль vsftpdЛокальные юзеры в $HOME, chroot, whitelist, SSL выключен
Состояние VNCНе запущен; слушал только localhost:5903, пароль задан
Облачные security-groupsРаз локальный firewall выключен — фильтрация только на уровне облакапроверить firewall-rules в консоли Yandex Cloud
Целостность/история (опц.)Не входило в audit.sh: capabilities, world-writable, bash_history, ошибки журналаgetcap -r / 2>/dev/null; journalctl -p err -b

13. План действий (приоритизированный)

🔴 Высокий приоритет

  1. Включить firewall (ufw/nftables, default deny incoming) и/или жёстко настроить облачные security-groups: разрешить SSH 48008, FTP-порты — только из доверенных подсетей, Zabbix/Acronis — с IP мониторинга.
  2. Разобраться с y4tsun0v: удалить аккаунт или убрать NOPASSWD:ALL из /etc/sudoers.d/90-cloud-init-users (orphan от первичной настройки, как и на первом сервере).
  3. Закрыть/защитить FTP: ограничить источники firewall'ом, перейти на FTPS/SFTP, убедиться, что vsftpd (48080) и ftp-proxy (21001–21004) недоступны за пределами доверенного периметра.
  4. Сократить десктоп-стек: если GUI не нужен — отключить lightdm, cups/cups-browsed, avahi-daemon, colord, switcheroo-control. Если нужен (АРМ ViPNet) — трактовать узел как рабочую станцию и изолировать соответственно.

🟠 Средний приоритет

  1. Группа docker: пересмотреть членство r3ddan9/evrotrans — это root-эквивалент в обход паролей. Минимум для evrotrans (сервисный аккаунт) рассмотреть отказ от прямого доступа к Docker.
  2. %google-sudoers / метаданные Yandex Cloud: проверить, кто реально попадает в эту группу через облако; ограничить OS Login.
  3. Avahi/mDNS: выключить на серверном узле (systemctl disable --now avahi-daemon).
  4. X11Forwarding no в sshd_config, если проброс X11 не используется.
  5. Установить fail2ban (на будущее) и/или продолжать держать SSH вне публичного интернета.
  6. Политика паролей: задать PASS_MAX_DAYS (напр. 365) — важно из-за локального входа через LightDM.
  7. Пересобрать Docker-образы FTP (крутятся 4 месяца) для получения свежих патчей.

🟢 Дополнительно

  1. Перепроверить ключи r3ddan9/evrotrans и состояние VNC (см. §12).
  2. Проверить права на ~/.vnc/*SrvKey.pem и .vipnet/.../for_rand.key (600, владелец evrotrans).
  3. Проаудировать .env и docker-compose.yml FTP-стека на хранение паролей в открытом виде.
  4. Развести переиспользуемый ключ danil@IdeaPad на отдельные ключи по ролям/хостам.

14. Что настроено хорошо (сохранить)

15. Сравнение с первым сервером (...-global-...)

АспектСервер 1 (web/global)Сервер 2 (vipnet)
РольВеб/ERP + OpenVPN + PortainerFTP-стек + ViPNet + десктоп (GUI)
Публичные сервисы80/443/1194/FTP/SSHFTP/SSH (web нет)
Вход извнеС публичных резидентных IP + брутфорсТолько внутренняя сеть, брутфорса нет ✅
Firewall(не подтверждён)🔴 выключен
Десктоп-стекнет🔴 LightDM/Xorg/VNC/CUPS/Avahi
y4tsun0v NOPASSWD🔴 есть🔴 есть (та же проблема)
Группа docker🟠 r3ddan9 + evrotrans
Приватные ключи в дереве приложения🔴 id_rsa, OpenVPN CA/server, Portainerпочти нет (VNC/ViPNet системные)
Переиспользуемый ключ danil@IdeaPadдада (тот же ключ — связывает оба узла)
Общие системные проблемы обоих узлов: orphan y4tsun0v с беспарольным root и один и тот же личный SSH-ключ danil@IdeaPad-3-14ALC6. Их стоит исправлять централизованно на всём парке (см. общую карту).