🛡 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