SSH на максималках: Ускоряем повторные подключения с помощью ControlMaster

Каждый Linux-админ использует ssh десятки раз в день. Мы привыкли к небольшой задержке при каждом подключении: рукопожатие, обмен ключами, аутентификация. Но что, если я скажу, что ждать нужно только один раз?

Знакомьтесь с SSH Multiplexing (мультиплексированием) — встроенной функцией OpenSSH, которая делает повторные подключения к одному и тому же хосту практически мгновенными.

▪️ Как это работает?
При первом подключении ssh создает управляющий сокет — постоянное «мастер-соединение». Все последующие сессии (ssh, scp, sftp) к этому же хосту просто переиспользуют этот уже установленный и аутентифицированный канал, пропуская всю рутину.

▪️ Как включить?
Добавьте эти строки в ваш файл ~/.ssh/config:

Ini, TOML

Host *
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 10m

ControlMaster auto: Автоматически создавать и использовать мастер-соединение.

ControlPath ...: Шаблон для именования файлов сокетов (создаст уникальный сокет для каждой сессии).

ControlPersist 10m: Оставлять мастер-соединение активным в фоне 10 минут после закрытия последней сессии.

▪️ Проверьте сами:

Откройте терминал и подключитесь к серверу: ssh user@your-server. Вы заметите обычную задержку.

Не закрывая первое соединение, откройте второй терминал и выполните ту же команду.

Вы подключитесь мгновенно.

🧠 Взгляд архитектора:
Это не просто личный лайфхак. Для систем автоматизации вроде Ansible эта функция — настоящее золото. Она может кардинально ускорить выполнение плейбуков на множестве хостов, так как Ansible не тратит время на установку нового SSH-соединения для каждой задачи. Это напрямую влияет на скорость и эффективность деплоя.

#SSH #Linux #DevOps #Performance #LifeHack #SysAdmin

Аудит и чистка SSH-ключей в authorized_keys

Со временем файлы ~/.ssh/authorized_keys на серверах превращаются в свалку из десятков ключей: от бывших сотрудников, старых ноутбуков, CI/CD систем. Каждый забытый ключ — это потенциальная дверь в вашу инфраструктуру.

Воскресенье — идеальное время для ревизии.

Ваш чек-лист по аудиту:

Найдите все файлы authorized_keys:

Bash

# Ищем в домашних директориях и у root
find /home /root -name "authorized_keys"

Проверьте на слабые типы ключей:
Ключи ssh-dss (DSA) и ssh-rsa длиной 1024 бит считаются устаревшими и небезопасными.

Bash

# Эта команда подсветит строки со старыми типами ключей
grep -E 'ssh-dss|ssh-rsa' /path/to/authorized_keys

Что делать: Свяжитесь с владельцем и попросите сгенерировать новый ключ типа ed25519 или rsa (3072/4096 бит).

Добавьте осмысленные комментарии:
Каждый ключ должен иметь комментарий, отвечающий на вопрос «Кто, откуда и когда?». Это золотой стандарт.

ssh-ed25519 AAAA... alice@workstation-2025-10-05
ssh-ed25519 AAAA... jenkins-ci@build-server

Сверяйте отпечатки (fingerprints):
Чтобы не сравнивать гигантские строки, получите отпечаток публичного ключа. Это проще и надёжнее.

Bash

# Команда выполняется на машине, где лежит ПУБЛИЧНЫЙ ключ
ssh-keygen -lf my_key.pub

Сравните его с отпечатком ключа на сервере.

Взгляд архитектора:
Это не просто уборка, это управление жизненным циклом доступа. В зрелых системах доступ должен быть не только выдан, но и своевременно отозван. Регулярный аудит ключей — это базовый элемент гигиены безопасности, который предотвращает инциденты, а не реагирует на них.

#linux #security #ssh #audit #гайд #чеклисты

SSH: Ваш сервер — крепость или проходной двор? Аудит конфигурации с ssh-audit

Мы уже говорили о чистке authorized_keys. Но безопасность SSH — это еще и правильная конфигурация самого сервера (sshd_config). Какие алгоритмы шифрования разрешены? Используются ли устаревшие протоколы?

ssh-audit — это утилита, которая подключается к вашему SSH-серверу и проверяет его конфигурацию на соответствие современным стандартам безопасности.

Установка:
Bash

# pip (Python)
pip install ssh-audit

# Homebrew (macOS)
brew install ssh-audit

Использование:

Bash

# Запускаем аудит удаленного сервера
ssh-audit my-server.com

# Можно указать порт
ssh-audit -p 2222 my-server.com

Что вы увидите в отчете:

[INFO] — Информационные сообщения.
[WARN] — Предупреждения (например, использование CBC-шифров).
[FAIL] — Критические проблемы (например, включен протокол SSHv1 или слабые MAC-алгоритмы).

Для каждого пункта утилита даст рекомендацию, какие строки нужно добавить или изменить в /etc/ssh/sshd_config, чтобы исправить проблему. Например, так:

# Пример рекомендации

(fail) diffie-hellman-group1-sha1 is not recommended
(info) recommend removing the following KEX algorithm(s):
(info)     diffie-hellman-group1-sha1

Взгляд архитектора:
Безопасность — это не разовое действие, а непрерывный процесс. ssh-audit — это инструмент для автоматизированного аудита и валидации конфигураций. Его можно встроить в CI/CD пайплайн для проверки образов VM или запускать по расписанию для мониторинга "дрифта" конфигурации на действующих серверах, гарантируя соблюдение единого стандарта безопасности.

#security #ssh #audit #linux #команды

Security (Infrastructure): Смерть authorized_keys. Переходим на SSH-сертификаты

Боль: У вас 100 серверов и 10 админов. Вы копируете их публичные ключи (id_rsa.pub) в файл ~/.ssh/authorized_keys на каждый сервер.

Проблема 1: Админ уволился. Нужно удалить его ключ со 100 серверов.

Проблема 2: Админ потерял ноутбук. Его ключ скомпрометирован навсегда.

Решение: SSH Certificate Authority (CA) Netflix, Facebook и Uber не используют статические ключи. Они используют сертификаты. Это встроенная функция OpenSSH, о которой мало кто знает.

Как это работает:

Вы создаете CA: Генерируете "мастер-ключ" (храните его в сейфе/Vault).

На серверах: В sshd_config прописываете одну строчку: "Доверяй всем ключам, подписанным этим CA". (Файл authorized_keys больше не нужен!).

Вход админа:

Админ кидает свой pub-ключ в ваш Vault (или подписывающий сервис).

Вы (или SSO) проверяете его личность.

Вы подписываете его ключ своим CA со сроком жизни 1 час.

Админ заходит на серверы.

Через час: Сертификат "протухает". Доступа нет.

Взгляд архитектора: Это переход от статического доступа к эфемероному. Вам больше не нужно "ротировать" ключи или чистить серверы. Доступ выдается Just-in-Time (JIT).

#security #ssh #linux #zerotrust #architect #vault #гайд

🛡 Linux Security: Базовый аудит SSH за 5 минут

SSH — главная дверь в ваш сервер. Если она открыта слишком широко, ждите гостей (ботов). Вот 5 настроек в /etc/ssh/sshd_config, которые нужно проверить прямо сейчас.

1. Запрещаем вход от root Администратор должен заходить под своим пользователем и повышать привилегии через sudo.

PermitRootLogin no

2. Отключаем вход по паролям Только SSH-ключи. Пароли брутфорсятся, ключи — нет (в разумные сроки).

PasswordAuthentication no
PubkeyAuthentication yes

3. Меняем стандартный порт (Опционально, но полезно) Это не защита от целенаправленной атаки, но снизит шум в логах от 99% скрипт-кидди и ботов.

Port 2222  # Не забудьте открыть порт в firewall перед рестартом!

4. Ограничиваем пользователей Если на сервере 10 юзеров, а по SSH ходить нужно только двоим — укажите их явно.

AllowUsers admin_user deploy_bot

5. Отключаем X11 Forwarding Если вы не запускаете графические приложения удаленно (а на сервере вы этого делать не должны), закрываем вектор атаки.

X11Forwarding no

📌 Финал: Проверяем конфиг и перезапускаем службу:

sshd -t
systemctl restart sshd

#linux #security #ssh #чеклисты #adminfuture

🔔 Bash: Уведомление в Telegram при входе по SSH

Хотите знать, если кто-то (или вы сами) зашел на критический сервер? Простой скрипт, который отправляет алерт в Telegram при каждой успешной SSH-сессии.

1. Создаем скрипт /usr/local/bin/ssh-alert.sh:

#!/bin/bash
TOKEN="ВАШ_БОТ_ТОКЕН"
CHAT_ID="ВАШ_ID"
URL="https://api.telegram.org/bot$TOKEN/sendMessage"
MSG="🚨 SSH Login: $USER from $SSH_CLIENT on $(hostname) at $(date)"

curl -s -X POST $URL -d chat_id=$CHAT_ID -d text="$MSG" > /dev/null

Не забудьте: chmod +x /usr/local/bin/ssh-alert.sh

2. Добавляем в глобальный профиль: Открываем /etc/profile (сработает для всех юзеров) и добавляем в конец:

/usr/local/bin/ssh-alert.sh

Теперь, если кто-то подберет пароль или украдет ключ — вы узнаете об этом первым (и успеете дернуть рубильник).

#linux #security #ssh #telegram #scripting #monitoring

🛡 Tmux: Искусство "Бессмертной сессии"

Вы запустили долгий скрипт (обновление базы, компиляция) по SSH. Мигнул интернет. VPN отвалился. Итог: SSH-сессия разорвана, скрипт убит, данные в базе повреждены.

Архитектор никогда не работает в "голом" SSH. Он работает в tmux (Terminal Multiplexer).

Суть: tmux запускает виртуальный терминал на сервере, который не зависит от вашего подключения.

Шпаргалка за 30 секунд:
1. Запуск: tmux (вы внутри).
2. Запускаем скрипт: ./long-script.sh.
3. Отключаемся (Detach): Нажимаем Ctrl+B, отпускаем, жмем D.

Вы вышли в обычную консоль. Можно закрыть ноутбук, уйти домой.

Возвращаемся (Attach):

tmux attach

Магия! Скрипт всё еще бежит, курсор там же, где вы его оставили.

Сделайте привычкой: зашли на сервер — сразу набрали tmux. Это ваша страховка от разрывов связи.

#linux #tmux #ssh #productivity #skill #terminal

🚪 SSH: Не пускай никого, кроме избранных (AllowUsers)

Все знают: надо отключать вход по паролю ( PasswordAuthentication no ) и вход рута ( PermitRootLogin no ). Но есть еще один слой защиты, который часто игнорируют — Белый список пользователей.

Допустим, у вас на сервере 50 пользователей (разработчики, сервис-аккаунты). Если у одного из них утечет ключ или пароль — хакер зайдет.

Сделайте так, чтобы по SSH могли заходить только админы.

Настройка /etc/ssh/sshd_config : В конец файла добавьте:

Фрагмент кода

# Разрешить вход ТОЛЬКО этим пользователям
AllowUsers admin deploy_bot manager@192.168.1.*

Фишки:

1. Можно указать конкретные логины.

2. Можно привязать логин к IP (manager@IP).

3. Все остальные пользователи (даже если у них есть правильный пароль/ключ) получат "Permission denied".

Это железобетонная защита от случайных дыр в забытых аккаунтах.

#linux #ssh #security #hardening #bestpractice #config

🧠 Skill: SSH Jump Host (Прыжок через шлюз)

Ситуация: Сервер DB-Server (10.0.0.5) находится в закрытой сети.
Доступ к нему есть только с Gateway-Server (1.2.3.4).
Плохой путь: Зайти по SSH на Gateway, оттуда по SSH на DB. Неудобно копировать файлы (scp), не работают туннели.

Путь Архитектора (ProxyJump): Используем флаг -J (Jump).
SSH сам прокинет соединение через промежуточный узел.

Команда:

ssh -J user@1.2.3.4 user@10.0.0.5

Чтобы не писать каждый раз (добавьте в ~/.ssh/config):

Host db-prod
    HostName 10.0.0.5
    User admin
    ProxyJump admin@1.2.3.4

Теперь вход одной командой: ssh db-prod. Работает и для scp, и для Ansible.

#ssh #network #security #tips #jumphost

🛡️ SSH: Защита от Bruteforce без Fail2Ban? Используем SSH ProxyJump и внутренние лимиты

Многие по привычке ставят Fail2Ban, который парсит логи и забивает таблицу iptables тысячами правил. Но в современных дистрибутивах можно ограничить количество попыток соединений на уровне самого демона или использовать «прыжковый» сервер.

Если вам нужно быстро ограничить аппетиты ботов, обратите внимание на параметр MaxStartups в sshd_config.

Как настроить:

В файле /etc/ssh/sshd_config: MaxStartups 10:30:60

Что это значит:

1. 10: До 10 одновременных неавторизованных подключений разрешены.

2. 30: Если их больше 10, SSH начнет сбрасывать новые попытки с вероятностью 30%.

3. 60: Если попыток больше 60, все новые подключения будут блокироваться до завершения старых.

Это защищает от перегрузки процесса SSH и делает атаку методом перебора бессмысленной.

#security #ssh #linux #devops #hardening #admin

🛡️ Security: SSH Fingerprinting — как не стать жертвой Man-in-the-Middle

Когда вы первый раз подключаетесь к серверу, SSH спрашивает: "Are you sure you want to continue connecting?". 99% админов просто пишут yes. Но если кто-то подменил IP или перехватил трафик, вы отдадите свои ключи или пароль злоумышленнику.

Как проверить отпечаток сервера (Fingerprint) по-умному: Перед подключением запросите отпечаток ключа на самом сервере (через консоль ДЦ или KVM):

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Как проверить его локально: Если вы уже подключались и хотите убедиться, что ключ не изменился втихую:

ssh-keygen -l -f ~/.ssh/known_hosts -F [IP_ADDRESS]

Если отпечатки не совпадают — кабель вон из розетки, вас пытаются взломать.

#security #ssh #mitm #linux #infosec #hardening

🧠 Skill: Протокол SSH Multiplexing — ускоряем работу в 10 раз

Если ты часто прыгаешь по одним и тем же серверам, то знаешь, как бесит ждать 2-3 секунды, пока SSH установит соединение. В 2026 году админы используют Multiplexing, чтобы переиспользовать уже открытое TCP-соединение для новых сессий. 🚀

Как настроить в своем ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m

Что это дает:
1. Первое подключение: Обычное (ввод пароля/ключа).
2. Второе и последующие: Мгновенное открытие консоли (0.1 сек).
3. ControlPersist 10m: Соединение будет висеть в фоне 10 минут после закрытия последней сессии, чтобы ты мог вернуться мгновенно.

Это критически ускоряет работу Ansible и твоих собственных Bash-скриптов, которые ходят по серверам. 🏎️

#skills #ssh #linux #performance #sysadmin #productivity #automation 🌐

🌐 Skill: SSH-туннелирование — пробиваем стены без VPN 🚇

Ситуация: Тебе нужно срочно подключиться к базе данных (PostgreSQL/MySQL) или веб-админке на закрытом сервере.
Порт базы (5432) закрыт файрволом и слушает только localhost.
VPN не настроен.
Всё пропало?

Нет. Если у тебя есть доступ по SSH (порт 22), у тебя есть доступ ко всему.

Команда 1: Local Port Forwarding (Проброс порта)
Мы «привязываем» удаленный порт к твоему ноутбуку.

# Синтаксис: ssh -L [Локальный_порт]:[Куда_хотим_попасть]:[Порт_цели] user@server
ssh -L 5432:localhost:5432 user@remote-server.com

Теперь в твоем DBeaver/PgAdmin просто пиши host: localhost, port: 5432.
Ты работаешь с базой так, будто она стоит у тебя на машине.

Команда 2: Dynamic Port Forwarding (Твой личный SOCKS-прокси)
Нужно открыть внутренний корпоративный сайт, который доступен только из офиса?

ssh -D 8080 user@office-server

Теперь в настройках браузера (или через расширение FoxyProxy) ставь SOCKS5 прокси: localhost:8080. Весь твой трафик пойдет через этот сервер.

Итог: SSH — это легальный и самый надежный VPN, который всегда с тобой. 🛡️

#networking #ssh #tunneling #security #sysadmin #lifehack #proxy

🛡️ Security: SSH по нестандартному порту — защита от «шума» и сканеров 🚪

В условиях массовых блокировок VPN-протоколов, твой SSH-доступ становится основной мишенью для брутфорс-ботов. Оставлять порт 22 открытым в 2026 году — значит забивать логи гигабайтами мусора и рисковать тем, что ТСПУ сочтет твой трафик подозрительным.

Меняем правила игры:

Отредактируй /etc/ssh/sshd_config:

Port 2222 (выбери любой от 1024 до 65535)

Не забудь открыть порт в фаерволе:

ufw allow 2222/tcp

Перезапусти: systemctl restart ssh

Почему это важно: 99% автоматизированных сканеров и ботов «стучатся» только в 22 порт. Переезд на другой порт снижает нагрузку на CPU (от обработки неудачных попыток входа) и делает твой сервер менее заметным для систем автоматического анализа трафика.

#security #ssh #hardening #linux #sysadmin #infosec #server #admin_future

🛡 Security: SSH Knocking — «невидимый» порт для тех, кто знает пароль ✊

Даже если ты сменил порт SSH на 2222, боты-сканеры всё равно его найдут.
Ультимативное решение — Port Knocking.
Твой SSH-порт будет закрыт полностью для всех (даже для тебя), пока ты не «постучишься» в другие закрытые порты в определенной последовательности.

Техническая реализация (через knockd):

Ты отправляешь серию TCP-пакетов на порты, например, 7000, 8000, 9000. Только после этого файрвол открывает 22 порт специально для твоего IP на 10 секунд.

Как проверить конфигурацию в Linux:

# Посмотреть статус службы knockd
sudo systemctl status knockd

# Пример стука с клиента (на Windows/Linux):
knock <IP_сервера> 7000 8000 9000 && ssh user@IP_сервера

Результат: Твой сервер выглядит абсолютно «мертвым» для любого внешнего сканера. Нет открытых портов — нет атак.

#security #ssh #portknocking #networking #infosec #sysadmin #hardening #admin_future

🛡️ Security: SSH-ключи с защитой от кражи (Ed25519-SK) и FIDO2 🔑

В 2026 году обычный SSH-ключ на диске — это риск. Если твой ноутбук взломают, ключ улетит к хакеру. Решение — использование аппаратных токенов (типа Yubikey) с типом ключа Ed25519-SK. Такой ключ физически привязан к «железке» и требует физического касания токена для входа.

Как это работает:

Приватная часть ключа хранится внутри защищенного чипа токена. Даже если файл-заглушка на ПК будет украден, без физического устройства он бесполезен.

Команда для генерации защищенного ключа:

# Генерируем ключ, привязанный к аппаратному токену
ssh-keygen -t ed25519-sk -O resident -O application=ssh:admin-future

Параметр -O resident позволяет сохранить «ссылку» на ключ прямо на токене, чтобы ты мог зайти на сервер с любого ПК, просто воткнув свой USB-ключ.

#security #ssh #fido2 #yubikey #infosec #hardening #sysadmin #admin_future

🐧 Linux: Хватит раскидывать ключи ssh-rsa. Переходим на SSH-сертификаты

Коллеги, управлять ключами SSH даже в небольшой команде — это боль. Мы генерируем ключи, копируем их в authorized_keys на десятки серверов. А когда администратор увольняется или теряет ноутбук, мы судорожно пытаемся вспомнить, на каких именно машинах нужно срочно зачистить его доступы. В 2026 году такой подход — это дыра в безопасности.

Современный стандарт — настройка внутреннего удостоверяющего центра (CA) для SSH.

Как это работает:

— Вы генерируете одну пару ключей для Удостоверяющего Центра (CA).
— Публичный ключ CA кладется на все ваши серверы в конфигурацию sshd.
— Когда инженеру нужен доступ, он отправляет свой публичный ключ на CA.
— CA выдает ему подписанный сертификат, в котором жестко указано: кому он выдан и сколько времени он действует (например, ровно 8 часов).

Зачем это нужно:
У вас на серверах больше нет файла authorized_keys с десятками непонятных строк. Вы полностью избавляетесь от процесса отзыва доступов. Если человек ушел в отпуск или уволился — его сертификат просто истекает к концу рабочего дня и превращается в тыкву. Взлом ноутбука инженера на выходных больше не дает хакеру ключи от всего продакшена.

Настроить SSH CA можно за пару часов встроенными средствами OpenSSH. Это тот самый случай, когда внедрение крутой безопасности делает жизнь админа проще, а не сложнее.

#linux #ssh #security #sysadmin #bestpractices #admin_future

🐧 Linux: CVE-2026-46333 — Qualys опубликовала полный advisory. Ротируй SSH-ключи.

Коллеги, свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.

TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.

На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.

# ШАГ 1: Патч уже есть — проверяем версию ядра
uname -r
# Патч в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
# Если старше — обновляем НЕМЕДЛЕННО:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 2: Была ли уязвимость активна? Смотрим были ли local users:
last | grep -v "^reboot\|^wtmp" | \
    awk '{print $1}' | sort -u
# Если только root — риск ниже. Если были другие — ротируем ключи.

# ШАГ 3: Ротация SSH host keys (если есть подозрение на компрометацию):
# Генерируем новые ключи:
rm /etc/ssh/ssh_host_*
ssh-keygen -A
# Перезапускаем SSH (NOT текущую сессию — откроем новую первой):
systemctl restart sshd

# Обновляем known_hosts на всех клиентах:
ssh-keyscan -H <server_ip> >> ~/.ssh/known_hosts

# ШАГ 4: Митигейшн если патч ещё не применён:
# ptrace_scope = 2 блокирует только root может ptrace непривилегированных
echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope = 3 — полный запрет (ломает отладчики, gdb, strace)

Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.

Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.

#linux #cve #ssh #security #kernel #sysadmin #admin_future

🐧 Linux: CVE-2026-46333 — Qualys опубликовала четыре рабочих эксплойта. Меняем shadow.

Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.

Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.

Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.

# ПАТЧ ЕСТЬ — проверяем прямо сейчас:
uname -r
# Патч в коммите Линуса "ptrace: slightly saner get_dumpable() logic"
# Закрыт в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 5.15.207 / 5.10.256

# Обновляем если старее:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# ЕСЛИ НА ХОСТЕ БЫЛИ ЛОКАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ В МАЕ:
# 1. Ротируем SSH host keys:
rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
ssh-keygen -A
systemctl restart sshd

# 2. Ротируем пароли учёток из /etc/shadow:
# (shadow мог быть прочитан через chage-эксплойт)
# Минимум — все системные аккаунты с shell:
awk -F: '$7 !~ /nologin|false/ && $3 >= 1000 {print $1}' \
    /etc/passwd | while read u; do passwd --expire $u; done

# 3. Митигейшн если патч ещё не применён:
echo "kernel.yama.ptrace_scope = 2" >> \
    /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope=2: только root может ptrace непривилегированных процессов

Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.

Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.

#linux #cve #ssh #kernel #security #sysadmin #admin_future