Это перевод оригинальной статьи Linux Outage Triage: 20 Commands I Run Before I Touch Anything.

Когда сбой происходит в 3 утра, самый быстрый способ потерять время — начать «пробовать что-то».

Случайные перезапуски. Случайные изменения конфигурации. Случайное масштабирование.

Они часто только усугубляют ситуацию.

После 5 лет дежурств я понял, что настоящее реагирование на инциденты — это не вопрос остроумия, а вопрос систематичности.

После каждого сбоя я изо всех сил пытаюсь ответить на три вопроса:

Что сломалось? (симптомы)
Где произошло повреждение? (радиус)
Что изменилось? (движение к первопричине)

Это мой список команд для дежурных — готовый к копированию и вставке, сгруппирован по назначению.

⚡ Первые 3 минуты (скопируйте/вставьте этот блок)

Когда срабатывает алерт, я выполняю следующую последовательность действий:

uptime
top -o %CPU
free -h
df -h && df -i
ss -tulpn
journalctl -xe --no-pager | tail -n 80

Что вам это покажет за 60 секунд

✅ uptime → Средняя загрузка + стабильность системы
✅ top → Основные потребители CPU (CPU действительно является проблемой?) ✅ free -h → Давление на память / активное использование swap
✅ df -h / df -i → Диск заполнен ИЛИ исчерпаны inodes (оба случая могут «убить» систему)
✅ ss -tulpn → Что слушает порты + какие порты открыты (или отсутствуют) ✅ journalctl -xe → Последние критические ошибки, о которых сигнализирует система

Эти 6 команд позволяют вам получить контекст инцидента менее чем за минуту.

Теперь давайте углубимся в тему.

Раздел 1: хост выходит из строя? (CPU / Load)

uptime
top -o %CPU
ps aux --sort=-%cpu | head -n 15
mpstat -P ALL 1
pidstat 1

Используйте это, когда: всё работает медленно, запросы истекают по таймауту, срабатывают предупреждения о загрузке ЦП.

На что обратить внимание:

• Средняя загрузка процессора значительно превышает количество ядер CPU.
• Один процесс постоянно потребляет ресурсы процессора.
• Процессор работает нормально, но система тормозит → часто возникает задержка ввода-вывода (переход к разделу "Диск")

Пример из практики: средняя загрузка 47% на 8-ядерном сервере. Оказалось, что это был неконтролируемый скрипт на Python, потребляющий 780% ресурсов CPU (многопоточно). pidstat отобразил точный PID.

Раздел 2: давление на память / OOM

free -h
ps aux --sort=-%mem | head -n 15
dmesg -T | tail -n 120
journalctl -k --no-pager | tail -n 120

Используйте это в следующих случаях: сервисы перезапускаются случайно, поды/демоны падают, сервер нестабилен.

На что обратить внимание:

• Логи OOM killer: "Killed process 12345 (java) ..."
• Использование swap быстро растёт (80%+ — опасная зона)
• Один процесс раздувается в памяти

Ключевое правило: сначала фиксируйте доказательства (логи + снимок памяти), прежде чем перезапускать что-либо.

Почему? После перезапуска все улики исчезают. Вы не узнаете, что на самом деле произошло.

Раздел 3: заполнение диска или заполнение инода (оба фактора приводят к сбоям)

df -h
df -i
du -sh * 2>/dev/null | sort -h | tail -n 15

Используйте это в следующих случаях: ошибки записи, сбои приложений, некорректная работа баз данных, зависание деплоя.

На что обратить внимание:

• Использование диска составляет 95–100%.
• Заполненность инодов составляет 100% (часто из-за миллионов маленьких лог-файлов).

Полезный совет: df -i команда, о которой все забывают. Я видел трехчасовые сбои, вызванные исчерпанием inode, когда диск был заполнен всего на 60%.

Раздел 4: удаленные файлы продолжают занимать место на диске (незаметный сбой)

lsof +L1

Используйте это, когда: df -h сообщает о заполнении диска, но вы "удалили 50 ГБ логов", и место не восстановилось.

Причина: удаленный файл по-прежнему остается открытым в рамках какого-либо процесса.

Как исправить: Перезапустить конкретный процесс (после сбора доказательств).

Пример из практики: однажды я потратил 2 часа на отладку дискового пространства. В логах было указано 89% заполнения. Удалил 40 ГБ. 89% всё ещё оставалось. Запустил команду lsof +L1→ обнаружил Java-процесс, удерживающий удалённый файл размером 45 ГБ. Перезапуск мгновенно исправил проблему.

Раздел 5: узкое место дискового ввода-вывода (система медленная, CPU в порядке)

iostat -xz 1
vmstat 1

Используйте это в следующих случаях: скачки задержки, зависание хоста, но загрузка ЦП не слишком высока.

На что обратить внимание:

• Долгое время ожидания диска (>50 мс — плохо, >100 мс — критично).
• vmstat показывает ожидания ввода-вывода / заблокированные процессы

Это самая распространенная ошибка в диагностике. Люди видят сообщение «система работает медленно» и предполагают, что проблема в процессоре. Часто же дело в дисковом вводе-выводе.

Раздел 6: что слушает? (порты + сервисы)

ss -tulpn
ss -s

Используйте это в следующих случаях: «Соединение отклонено», проверки работоспособности завершаются неудачей, трафик не доходит до сервиса.

На что обратить внимание:

• Сервисный порт не прослушивается (распространенная проблема после неудачного деплоя).
• Слишком много сокетов / давление соединений

Раздел 7: активные соединения

ss -tan state established | wc -l
ss -tan | head -n 30

Используйте это в следующих случаях: внезапный всплеск трафика, перегрузка соединений, неожиданное поведение клиентов.

На что обратить внимание:

• Огромное количество установленных соединений (>10 тыс. на одном хосте)
• Множество соединений находятся в странном состоянии (это может указывать на проблемы с вышестоящим сервером).

Раздел 8: основные сведения о сети (интерфейсы + маршруты)

ip a
ip r

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

На что обратить внимание:

• Отсутствует интерфейс / неправильно назначен IP-адрес
• Неверный маршрут по умолчанию
• Изменения маршрута после перезапуска или обновления конфигурации

Раздел 9: быстрая проверка доступности

ping -c 3 <target>
curl -I http://<service>
curl -vk https://<service>

Используйте это, когданужно понять кто виноват: сеть или приложение.

Полезный совет: curl -vk бесценен для отладки TLS (цепочка сертификатов, ошибки рукопожатия, перенаправления, проблемы с SNI).

Раздел 10: состояние сервиса (systemd)

systemctl status <service>
systemctl is-active <service>
systemctl restart <service>

Используйте это, когда: подозреваете, что сервис сам упал или перезапускается в цикле.

Золотое правило: перед перезапуском сначала прочтите логи. В противном случае вы просто будете гадать.

Раздел 11: логи сервиса

journalctl -u <service> --since "30 min ago" --no-pager | tail -n 200
journalctl -u <service> -f

Используйте это, когда вам необходимо определить первопричину проблемы (ошибки конфигурации, сбои зависимостей, ошибки аутентификации).

Совет: используйте --since "30 min ago" параметр для снижения уровня шума. В большинстве случаев сигналы о сбоях в последних 30 минутах.

Раздел 12: последние системные ошибки (ядро + система)

journalctl -p err..alert --since "1 hour ago" --no-pager
dmesg -T | tail -n 120

Используйте это, когда вы подозреваете проблемы с ядром, драйвером диска или сети, либо обнаружили странное поведение хоста.

Что выявляет: ошибки нехватки памяти (OOM kill), сбои ядра, ошибки драйверов, аппаратные ошибки.

Раздел 13: что изменилось? (изменения конфигурации / временные метки)

ls -ltr /etc/<app>/
stat /etc/<app>/<config>

Используйте это, когда: сбои начался «после чего-то», но никто не помнит, после чего именно.

Почему это важно: 80% сбоев вызваны изменениями. Найдите изменение, найдите причину.

Раздел 14: Поиск сигналов в логах

grep -R "ERROR\|FATAL\|panic\|exception" -n /var/log/<app>/ 2>/dev/null | tail -n 50

Используйте это, когда логов слишком много, нужен моментальный вывод ошибок.

Альтернативный вариант journalctl -p err для сервисов, управляемых systemd.

Раздел 15: владение процессом (что это запустило?)

ps aux | grep <process_name>
pstree -ap | head -n 40

Используйте это, когда нужно увидеть parent/child связи (особенно runaway процессы).

Пример использования: зомби-процесс, который постоянно перезапускается. pstree показывает родительский процесс, который необходимо завершить.

Раздел 16: кто недавно вносил изменения в файлы?

find /etc/<app>/ -type f -mmin -120 -ls 2>/dev/null

Используйте это, когда каталог конфигурации большой, и вам нужно узнать, что изменилось за последние 2 часа?

Полезное решение: используйте совместно с stat, чтобы увидеть точное время внесения изменений и того, кто их внес.

Раздел 17: проверки DNS (да, часто виноват DNS)

resolvectl status 2>/dev/null || cat /etc/resolv.conf
dig +short <domain>
nslookup <domain>

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

Интересный факт: по моему опыту, 30% «загадочных сетевых проблем» — это DNS. Проверяйте его на раннем этапе.

Раздел 18: Отслеживание пути запроса (быстро)

traceroute <target> 2>/dev/null || tracepath <target>

Используйте это в следующих случаях: трафик между хостами/VPC/подсетями пропадает.

Что это показывает: где происходит потеря пакетов (правила брандмауэра, «черные дыры» маршрутизации, проблемы с пирингом VPC).

Раздел 19: Нехватка файловых дескрипторов (слишком много открытых файлов)

ulimit -n
lsof | wc -l

Используйте это в случаях, когда возникают странные сбои ввода-вывода, ошибки «слишком много открытых файлов», сбои под нагрузкой.

Распространенная причина: приложение не закрывает соединения/файлы должным образом. Проверьте код приложения.

Раздел 20: проверка времени (дрейф времени нарушает аутентификацию + TLS)

timedatectl status
date

Используйте это в случаях когда токены не проходят проверку, появляются ошибки TLS, распределённые системы ведут себя нестабильно.

Почему это важно: смещение времени более чем на 5 секунд может привести к поломке:

• Проверки JWT-токена
• Проверки TLS-сертификата
• Распределенного консенсуса (Raft, Paxos)
• Базы данных временных рядов

Распространенные ошибки, усугубляющие инциденты

Я совершал все эти ошибки. Учитесь на моих ошибках:

1. Перезапуск до сбора логов/доказательств → вы теряете неопровержимые улики. Всегда сначала фиксируйте данные.

2. Игнорирование df -i (инодов) → диск может быть заполнен на 60%, но система выйдет из строя, потому что иноды заполнены на 100%.

3. Предположение, что высокая загрузка CPU означает активные вычисления → Часто это задержка ввода-вывода, маскирующаяся под загрузку ЦП.

4. Отладка одного узла без проверки масштаба воздействия → Это касается одного хоста или всех хостов? Выясните это в первую минуту.

5. Устранение симптомов без выяснения причины изменения → Сбой повторится. Найдите первопричину.

✅ Краткий справочник: Схема команд при сбоях (краткое руководство на 1 минуту)

Ситуация: пользователи сталкиваются с тайм-аутами

uptime + top + ss -tulpn + journalctl -u <service>

Ситуация: всё работает медленно, но процессор, похоже, в норме.

iostat -xz 1 + vmstat 1

Ситуация: запись не выполняется / деплой не удаётся

df -h + df -i + lsof +L1

Ситуация: сервис работает, но по-прежнему недоступен.

journalctl -u <service> + grep errors + stat /etc/<service>/

Главный вывод

Реагирование на сбои — это не значит быть самым умным человеком в комнате.

Речь идёт о систематическом подходе.

Эти 20 команд — это моя система.

Скопируйте их. Вставьте. Создайте свой собственный runbook.

А когда в 3 часа ночи сработает сигнал тревоги, вы будете точно знать, с чего начать.

Это перевод оригинальной статьи The Hidden Magic of the Linux Terminal.

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

От говорящих коров до терминалов, имитирующих The Matrix, эти команды напоминают нам, что Linux не только мощный, но и забавный. Ниже приведены десять команд, в существование которых трудно поверить.

rev – команда, которая всё переворачивает с ног на голову

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

Введите команду echo hello | rev, и в результате вы получите olleh. Это обманчиво просто, но удивительно удобно. Разработчики используют её для обработки палиндромов, отладки скриптов или манипулирования форматами вывода. rev воплощает элегантность философии UNIX: делай одно дело, и делай его идеально.

cowsay –когда корова высказывает ваше мнение

Наберите текст cowsay "Keep coding" и наблюдайте, как ASCII-персонаж в виде коровы «произносит» ваши слова в мультяшном облачке с текстом.

Эта забавная команда была придумана исключительно ради развлечения, но быстро стала культовой среди разработчиков. Вы даже можете заменить корову другими персонажами, например, драконом или пингвином в смокинге, используя флаг -f.

cowsay превращает терминал, место логики, в полотно юмора.

sl – паровоз, который наказывает за опечатки

Каждый пользователь Linux хоть раз ошибочно вводил ls как sl. Вместо сообщения об ошибке эта команда запускает полноценную ASCII-анимацию паровоза, проезжающего по вашему терминалу.

Изначально это было написано как шутка, чтобы «наказать» невнимательных наборщиков текста, но с тех пор стало любимой пасхальной отсылкой в ​​мире Linux. Некоторые системные администраторы намеренно устанавливают её на боевые системы, чтобы напомнить своим командам, что даже у машин есть чувство юмора.

yes – бесконечный цикл согласия

yes — одна из самых простых и одновременно самых странных команд в мире. Наберите yes, и ваш терминал будет бесконечно заполняться символом «y».

Но у этого инструмента есть и практическое применение: его часто используют для автоматизации ответов в скриптах или системах тестирования производительности, обрабатывающих непрерывный ввод. Например, yes | apt-get install package позволяет обойти запросы подтверждения. То, что на первый взгляд кажется абсурдным, на практике становится рабочей лошадкой автоматизации.

toilet – типографика в терминале

Команда toilet преобразует обычный текст в большие, декоративные ASCII-заголовки. Нужен ли вам эффектный заголовок для лог-файла или вы просто хотите увидеть своё имя в эффектном терминальном формате — этот инструмент справится.

С такими параметрами, как --gay, он даже выводит цветные градиенты текста. В сочетании с конвейерами из других команд он превращает системные логи в цифровые произведения искусства. Название может вызвать удивление, но результат его работы на удивление изысканный.

factor – математический минималист

Нужно разложить число на множители, не открывая калькулятор? Просто введите кfactor 12345, и Linux мгновенно разложит его на простые множители.

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

fortune – мудрость из командной строки

Команда fortune выдает случайные отрывки мудрости, юмора или абсурда. Запустите ее, и вы можете увидеть пословицу, цитату из фильма или ироничную шутку.

Она является частью культуры UNIX на протяжении десятилетий и часто используется для добавления индивидуальности в скрипты запуска или сообщения при входе в систему. В сочетании с cowsay ваша терминальная корова становится философом, произнося строки цифрового просветления.

rev + cowsay + fortune – сила цепочки команд

Одна из главных сильных сторон Linux — это цепочка команд. Вы можете комбинировать инструменты для получения удивительных результатов.

fortune | rev | cowsay создаёт корову, которая выводит перевёрнутые «предсказания» — игривый хаос конвейеров и процессов.

Этот синтез простоты и творчества демонстрирует суть Linux: модульность, экспериментирование и юмор, сосуществующие в одной командной строке.

rig – генерация фальшивых личностей

Нужен случайный адрес или имя для тестирования? rig (генератор случайных идентификационных данных) мгновенно создает поддельные личные данные, включая адреса улиц, почтовые индексы и имена.

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

cmatrix — матрица живёт в вашем терминале

Введите cmatrix, и ваш экран превратится в каскад неоново-зеленого текста — дань уважения фильму «Матрица».

Эта завораживающая команда превращает ваш терминал в цифровой дождь, дополненный случайными символами и плавной прокруткой. Она не выполняет никакой функциональной задачи, но идеально воплощает дух игривости открытого исходного кода. Потому что иногда код должен быть прекрасен сам по себе.

Игривое сердце Linux

Командная строка Linux — это не просто место для серьезных вычислений, это живая, дышащая вселенная творчества. Эти необычные команды, как практичные, так и причудливые, раскрывают индивидуальность платформы.

Они напоминают нам, что даже в мире автоматизации, оптимизации и управления есть место для радости.

Так что в следующий раз, когда вы откроете терминал, осмельтесь на исследование. Где-то между командами ls и sudo вас ждет корова, готовая заговорить, поезд, готовый отправиться в путь, и матрица, готовая пролиться дождем.

Это перевод оригинальной статьи 12 Best Kubernetes Security Tools You Need In 2026.

Одна из самых больших проблем в облачной инфраструктуре — это обеспечение безопасности Kubernetes. Понимание того, какие инструменты безопасности следует внедрять, может стать решающим фактором между хорошо защищённым и уязвимым кластером.

В этой статье мы рассмотрим основные инструменты Kubernetes, необходимые для обеспечения безопасности. С помощью этих инструментов вы сможете построить многоуровневую защиту, и мы рассмотрим инструменты, которые помогают реализовать подход shift-left, принудительное применение политик, защиту на этапе выполнения и даже аудит соответствия требованиям.

Если коротко, то посмотрите видео:

Инструменты безопасности Kubernetes с подходом shift-left

«Сдвиг влево» означает перенос вопросов безопасности на более ранние этапы цикла разработки. Вместо обнаружения уязвимостей и неправильных настроек в производственных средах, вы выявляете их на этапах разработки или непрерывной интеграции, когда их дешевле и проще исправить.

1. KubeLinter

KubeLinter — первая линия защиты, поскольку он проверяет манифесты Kubernetes и Helm-чарты на наличие ошибок конфигурации до фактического развертывания. Этот инструмент отлично справляется с выявлением распространенных проблем, таких как запуск контейнеров от имени root, использование тега latest у образов или отсутствие запросов и лимитов на ресурсы.

KubeLinter теперь поддерживается сообществом, и его скорость и простота делают его идеальным для CI/CD-пайплайнов, где критически важна быстрая обратная связь. Одна команда kubelinter lint может предотвратить появление проблем безопасности в вашем кластере, что делает этот инструмент мощной частью любого GitOps-процесса.

2. Checkov

Checkov — это инструмент статического анализа уязвимостей и ошибок конфигурации, который работает с Terraform, CloudFormation, Kubernetes и другими инфраструктурными решениями как код (IaC).

Он содержит более 1000 встроенных политик и выявляет неправильные конфигурации и нарушения соответствия стандартам, таким как CIS, NIST и другим. Это мощный инструмент, который следует использовать в CI/CD-пайплайнах, где необходимо обеспечить соблюдение корпоративных стандартов до запуска инфраструктуры в продакшн.

3. Trivy

Trivy от Aqua Security обнаруживает уязвимости в образах контейнеров, репозиториях Git, IaC и даже кластерах Kubernetes.

Trivy выделяется своей универсальностью и скоростью работы. Он сканирует на наличие известных уязвимостей (CVE), неправильных конфигураций, раскрытых секретов и даже проблем с лицензиями. Благодаря недавним обновлениям Trivy улучшил свои возможности по сканированию запущенных рабочих нагрузок, а также поддерживает генерацию Software Bill of Materials (SBOM), что важно для прозрачности безопасности цепочки поставки.

4. Kubescape

Kubescape, разработанный компанией ARMO, обеспечивает комплексную видимость безопасности от этапа разработки до выполнения. Платформа сканирует как YAML-манифесты, так и работающие кластеры, сравнивая их с такими фреймворками, как NSA/CISA и MITRE ATT&CK.

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

5. Cosign/Sigstore

Cosign, входящий в проект Sigstore, решает задачу безопасности цепочки поставки напрямую. С помощью Cosign вы можете подписывать образы контейнеров в процессе сборки и проверять подписи перед их развертыванием.

Это важно, поскольку предотвращается запуск в кластерах измененных или несанкционированных образов и можно легко убедиться в том, что ваши образы получены из надежных источников.

6. Kyverno

Kyverno — это проект CNCF на стадии инкубации, который стал популярным по простой причине: он позволяет писать политики Kubernetes в формате YAML.

Он может автоматически проверять, изменять и генерировать ресурсы. Это значительно упрощает внедрение правил, таких как «запрещать запуск подов от root» или «каждое новое пространство имён должно иметь сетевую политику по умолчанию». Он менее гибкий для сверхсложной логики по сравнению с конкурентами, но для большинства команд его простота и нативная интеграция с Kubernetes делают его отличным выбором.

7. OPA Gatekeeper

Open Policy Agent (OPA) с Gatekeeper представляет собой мощный инструмент для обеспечения соблюдения политик в Kubernetes. OPA — это проект, получивший одобрение CNCF, и универсальный механизм управления политиками, работающий со всем вашим технологическим стеком.

Он использует Rego — декларативный язык для описания политик, который сложнее в изучении, чем YAML в Kyverno. Если вам нужен единый язык политик для разных платформ и сервисов, OPA является отраслевым стандартом.

8. Falco

Falco — ещё один проект, завершивший программу CNCF, который является золотым стандартом в области обнаружения угроз в облачных средах.

Используя eBPF, Falco напрямую подключается к ядру Linux для наблюдения за системными вызовами и активностью контейнеров. Его правила можно настраивать для обнаружения аномалий, таких как неожиданный запуск shell в контейнере или несанкционированный доступ к файлам. Falco требует тонкой настройки для уменьшения количества ложных срабатываний, но его глубина наблюдаемости делает его крайне важным для production-сред.

9. Cilium

Cilium изменил подход к сетевой безопасности Kubernetes, используя eBPF для высокопроизводительной сетевой работы и защиты на уровне ядра Linux, устраняя необходимость в традиционных инструментах вроде iptables.

Сетевые политики Cilium работают на основе идентичностей сервисов и меток, а не IP-адресов. Он также включает Hubble — инструмент наблюдаемости, который позволяет в реальном времени визуализировать взаимодействие сервисов и упрощает диагностику и мониторинг безопасности.

10. Calico

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

Хотя ему, возможно, и не хватает всех впечатляющих преимуществ в производительности, присущих решениям на основе eBPF, таким как Cilium, его зрелость и мощные функции управления политиками делают его надежным выбором для защиты вашего кластера.

Аудит и соответствие требованиям

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

11. Kube-hunter

Хотя разработка Kube-hunter прекращена, и компания Aqua Security рекомендует вместо него Trivy, его все же стоит упомянуть по историческим причинам.

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

12. Kube-bench

Kube-bench превосходно справляется с одной задачей: он проверяет, соответствуют ли ваши развертывания Kubernetes стандартам CIS Kubernetes Benchmark от Center for Internet Security.

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

Заключение

Для эффективной защиты Kubernetes необходимо внедрять различные инструменты на разных уровнях. Начните с подхода shift-left, затем убедитесь, что включено принудительное применение политик, добавьте защиту во время выполнения, защитите сеть и обеспечьте соответствие нормативным требованиям.

Это перевод оригинальной статьи Why you should learn Awk in 2026.

Awk — это уникальный инструмент. Но на самом деле существует не так много альтернатив, которые были бы столь же универсально доступны, как awk.

Что такое awk?

Awk можно использовать как программу для обработки текста в терминале. Но если с помощью sed можно выполнять основные операции, то с помощью awk можно добавлять текст, выполнять вычисления и использовать сложные условные операторы.

Потому что awk — это язык программирования.

Awk прекрасно дополняет grep и sed, и для большинства задач по обработке текста вам больше ничего не понадобится. Там, где вам пришлось бы вручную редактировать файл с помощью Vim, вы можете использовать sed и awk для программного редактирования, и, следовательно, применять одни и те же изменения к нескольким файлам без необходимости переписывать что-либо заново.

Почему стоит изучать awk

Я начал изучать awk, потому что часто видел его в скриптах вместе с sed, и во всех курсах и видеороликах упоминались оба инструмента. Поэтому, когда я захотел изучить sed (поскольку он казался проще для понимания), я решил также начать изучать awk. И я сильно недооценил возможности awk и быстро понял, что awk действительно является языком программирования с такими возможностями, как условные конструкции, циклы, массивы и многое другое.

Я изучал его, потому что хотел использовать его вместе с sed и понять, что вообще возможно.

Теперь я знаю, что могу выполнять большинство правок структурированного текста с его помощью.

Примеры

Трудно представить себе, что можно сделать, сначала не увидев несколько примеров, не так ли? Давайте рассмотрим несколько.

Небольшие примеры

Awk полезен при работе с табличными данными, например, с выводом команды ls -l, когда вам нужно получить или только имена файлов, или только права доступа. С помощью символа $ можно указать столбец, который нужно вывести в каждой строке.

ls -l | awk '{ print $9 }'

Эта команда выведет имена файлов в текущем каталоге. Если использовать printf, можно вывести их в одну строку, разделённую пробелами, вместо переводов строки.

Можно также задавать условия для обработки строк.

awk -F, '$6 == "admin" {print $2, $NF}' users.csv

Этот небольшой скрипт выведет второй и последний столбцы для каждой строки в файле users.csv, определенном ниже в следующем разделе, но только для администраторов.

Как видно, даже простые однострочные команды уже могут давать более осмысленные выводы по данным или помогать на следующих этапах скрипта, например, чтобы пройтись по именам файлов в цикле

Пример awk-скрипта

Итак, представьте, что у вас есть CSV-файл, подобный этому.

id,name,email,age,country,role,signup_date,last_login,status
1,Alice Jansen,alice.jansen@example.com,28,NL,user,2023-01-14,2025-03-10,active
2,Bob de Vries,bob.devries@example.com,35,NL,admin,2022-11-03,2025-03-14,active
3,Charlie Smith,charlie.smith@example.com,22,UK,user,2024-02-20,2025-02-28,active
...

И вам нужно получить сводку статистики по пользователям. Конечно, вы можете сделать это любым удобным для вас способом, но давайте предположим, что нам нужен результат, подобный этому.

=== User Database Report ===
Active users:
Active in US:
Users under 30: 16
Total records processed: 16

Не задавайтесь вопросом зачем — просто примите это. Например, такой вывод может понадобиться в вашем CI/CD-пайплайне. Тогда можно создать awk-скрипт:

# summary.awk - Full user stats
BEGIN {
  print "=== User Database Report ==="
}
NR==1 { next }  # Skip header
{
  if ($9 == "active") {
    active++
    if ($5 == "US") us_active++
  }
  # Simple age group
  if ($4 < 30) young++
}
END {
  print "Active users:", active
  print "Active in US:", us_active
  print "Users under 30:", young
  print "Total records processed:", NR-1
}

Здесь мы создаём заголовок с помощью блока BEGIN, выполняем некоторые вычисления, а в конце выводим статистику.

И всё это — в awk. Теоретически это можно записать в одну строку, но проще сохранить в файл и использовать команду awk -f summary.awk users.csv.

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

Как научиться пользоваться Awk

Я изучал awk, проходя курс на Udemy, смотря видео на YouTube и экспериментируя самостоятельно. С тех пор я использую его в своих пайплайнах, и если у меня появляется свободное время, я могу придумать небольшую задачу и решить её с помощью sed и awk.

Также создал курс на Udemy по grep, sed и awk, поскольку эти три инструмента командной строки отлично работают вместе. Вы можете найти его здесь.

Заключение

Вместе с grep и sed awk является чрезвычайно универсальным инструментом для обработки текста. Поскольку его можно использовать программно, вы можете редактировать файлы внутри других скриптов (например, в скриптах настройки проекта). Большое спасибо за прочтение и хорошего вам дня!

Это перевод оригинальной статьи The Fastest Way to Back Up a File in Bash (You’re Probably Not Using It).

При работе в терминале создание резервной копии файла перед редактированием — это привычка, которая экономит время, нервы, а иногда и целые системы. В Bash есть приём, который делает это почти незаметным:

cp filename{,.bak}

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

Эта команда основана на расширении фигурных скобок — функции оболочки, которая генерирует несколько строк из одного шаблона.

filename{,.bak}

разворачивается в:

filename filename.bak

Таким образом, Bash фактически выполняет следующее:

cp filename filename.bak

Вы вводите имя файла один раз, а Bash сделает все остальное.

Почему это лучше, чем «обычный» способ

Большинство людей пишут:

cp filename filename.bak

Это работает, но расширение фигурных скобок имеет свои преимущества:

• Быстрый ввод
• Меньше ошибок, особенно с длинными именами файлов.
• Более чистые команды
• Упрощает чтение скриптов и истории терминала.

После привыкания, возвращаться к прежнему будет тяжело.

Примеры из практики

Перед редактированием конфигурационного файла:

cp nginx.conf{,.bak}

Перед изменением скрипта:

cp deploy.sh{,.bak}

Нужно откатить изменения?

mv filename.bak filename

Мгновенная отмена.

Полезные варианты

Разный суффикс:

cp file{,.old}
cp file{,.backup}

Резервная копия с отметкой времени:

cp file{,.$(date +%F)}

Результат:

file.2025-12-15

Интерактивный режим (запрашивает подтверждение перед перезаписью):

cp -i filename{,.bak}

Важные примечания

• Работает в Bash, Zsh и большинстве современных оболочек.
• Не работает в обычной оболочке sh (POSIX shell).
• Перезаписывает существующие файлы .bak, если не используется -i.

Почему это важно

Это маленький приём, но он формирует более безопасный рабочий процесс:

• Резервное копирование становится автоматическим
• Вы чаще будете их делать
• Ошибки обратимы

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

Заключительная мысль

Если вы ежедневно работаете в терминале, эта однострочная команда должна стать частью вашей мышечной памяти:

cp filename{,.bak}

Маленькая команда. Большая отдача.

Это перевод оригинальной статьи Linux System Security: How To Prevent Others From Doing “Bad Things” on a Shared Server.

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

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

Понимание модели безопасности в Linux

Для эффективного решения проблем безопасности необходимо сначала понять модель безопасности Linux. Давайте разделим компоненты Linux на два уровня: уровень ядра и уровень пользователя. Уровень пользователя выполняет различные задачи, используя интерфейсы, предоставляемые уровнем ядра.

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

Учитывая критическую важность безопасности ядра в Linux, стоит ли нам вкладывать значительные усилия в её защиту? На самом деле, подобно тому, как мы не слишком беспокоимся о деталях операционной системы при разработке приложений (особенно при использовании языков высокого уровня, таких как Java), нам не нужно уделять слишком много внимания безопасности ядра при рассмотрении безопасности Linux. Вместо этого следует сосредоточиться в первую очередь на безопасности пользовательского уровня. Для безопасности уровня ядра достаточно следовать рекомендациям по защите от известных уязвимостей, например, использовать официальные образы и регулярно их обновлять.

Поскольку большинство взаимодействий происходит на пользовательском уровне, давайте рассмотрим операции на этом уровне. В Linux все операции пользовательского уровня можно абстрагировать в следующий процесс: «Субъект -> Запрос -> Объект». Например, в операции «open /etc/passwd» субъект — это сам пользователь, запрос — операция чтения, а объект — файл /etc/passwd.

В этом процессе система безопасности ядра Linux обеспечивает контроль доступа на основе разрешений, предотвращая несанкционированный доступ к данным. Уровень пользователя Linux должен обеспечивать правильную настройку разрешений. Это ключ к безопасному совместному использованию сервера несколькими пользователями, что также является основной темой данной статьи.

Как золотое правило применяется в системах Linux?

Теперь, когда мы знаем, что основой безопасности систем Linux является правильная настройка прав доступа на уровне пользователя, давайте рассмотрим, как принципы Золотого правила аутентификации, авторизации и аудита применяются в системах Linux. Мы также выделим ключевые параметры безопасности, на которые следует обратить внимание в этих областях.

1. Механизмы аутентификации в Linux

Linux — многопользовательская операционная система, которая управляет и хранит пользовательскую информацию с помощью простых текстовых файлов. В этом контексте два важнейших файла: /etc/passwd и /etc/shadow.

В Linux файл /etc/passwd доступен для чтения всем пользователям и не хранит пароли напрямую из соображений безопасности. Вместо этого в поле пароля используется символ 'x' как заглушка. Информация о пароле пользователя хранится в файле /etc/shadow, доступном для чтения только пользователю ROOT.

Файл /etc/shadow содержит не только зашифрованные пароли, но и другие политики управления паролями, такие как количество дней, в течение которых пароль действителен, или количество дней до истечения срока действия пароля, по истечении которых должно быть выдано предупреждение. Мы можем изменить эти политики управления паролями с помощью команды chage. Например, следующая команда chage заставляет тестового пользователя менять пароль каждые 60 дней, тем самым снижая вероятность утечки пароля:

chage -M 60 test

Поскольку аутентификация — это функция, предоставляемая ядром Linux, проблема безопасности, на которой необходимо сосредоточиться на уровне пользователя, — это утечка идентификационной информации из-за слабых паролей. Для решения этой проблемы можно настроить соответствующие политики паролей в файле /etc/shadow. Кроме того, можно использовать такие инструменты, как John the Ripper, для обнаружения слабых паролей в Linux, используя известные базы данных слабых паролей. Следующая команда демонстрирует, как использовать John the Ripper для обнаружения слабых паролей:

unshadow /etc/passwd /etc/shadow > mypasswd
john mypasswd
john --show mypassw

2. Механизм авторизации в Linux

Согласно «золотому правилу», аутентификация — это лишь первый шаг, предоставляющий доверенную идентификацию. После получения этой идентификации необходимо обеспечить авторизацию, чтобы ограничить действия, которые может выполнять пользователь.

В Linux объектами (также известными как субъекты) являются только файлы и каталоги. Для этих двух типов объектов Linux определяет три типа прав доступа: чтение, запись и выполнение. Различия между этими правами доступа для файлов и каталогов можно увидеть в представленной сравнительной таблице:

Помимо этих стандартных разрешений, Linux предоставляет дополнительные теги разрешений для более детального управления. Например, Linux предлагает атрибуты файлов для дополнительной защиты. Установив бит неизменяемости с помощью chattr +i /etc/passwd, вы можете запретить любому пользователю изменять файл. Подробнее об атрибутах файлов можно найти в Википедии.

Ещё одна функция Linux — это «sticky bit», который в первую очередь используется для предотвращения манипуляций пользователей с файлами других пользователей. Например, команда chmod +t /tmp может запретить пользователям удалять файлы в директории /tmp, принадлежащем другим пользователям.

Это механизмы самозащиты при авторизации Linux, но как мы можем активно обеспечить безопасность этого процесса?

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

Чтобы решить проблемы с разрешениями, нам следует придерживаться принципа наименьших привилегий.

Давайте рассмотрим одну из самых распространённых проблем безопасности в системах Linux: неправильное использование прав ROOT. Многие пользователи, входя в систему Linux, первым делом запускают команду su чтобы получить полноценную оболочку ROOT-пользователя. Таким образом, им не придётся каждый раз временно повышать привилегии до уровня ROOT с помощью команды sudo для выполнения каждой операции.

Однако следует отметить важный момент: в среде ROOT-оболочки все запущенные процессы также имеют привилегии ROOT. Если вы запустите быстровозвращающийся процесс, например, cat, это не создаст особых проблем. Но если это длительный процесс, это может легко привести к злоупотреблению привилегиями.

Например, если вы запустите Redis или MySQL от имени пользователя ROOT, любой другой пользователь, подключающийся к этим службам, может косвенно получить привилегии ROOT. В большинстве случаев взлома сервера хакеры используют уязвимости в этих процессах с привилегиями ROOT для повышения своих привилегий.

Поэтому при запуске любых долговременных процессов необходимо придерживаться принципа наименьших привилегий. Это означает настройку минимально необходимых прав для запуска резидентных процессов в зависимости от требуемого уровня операций. Например, операции чтения/записи файлов в таких базах данных, как Redis и MySQL, не требуют наивысших привилегий ROOT.

Принцип наименьших привилегий критически важен в системах Linux. Вы можете спросить: при таком количестве операций в Linux, для каждой из них нужна индивидуальная настройка прав доступа? К счастью, это не так. Мы часто используем известные инструменты для реализации принципа наименьших привилегий при запуске резидентных процессов, и ваша задача — правильно запустить или настроить эти инструменты.

Например, вы можете запустить службу MySQL, используя mysqld, которая выделяет процессы MySQL пользователю "mysql" и запускает демон под ROOT-аккаунтом. Вот как это выглядит на практике:

root     297353  0.0  0.0 115432  1360 ?        S    Aug12   0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/mysql.pid
mysql    297553 31.3  4.3 11282756 5729572 ?    Sl   Aug12 22593:40 /usr/local/mysql/bin/m

Аналогично, при запуске Nginx, Nginx будет запускать рабочие процессы от имени пользователя «nobody». Конкретный эффект будет следующим:

root       7083  0.0  0.0  61032  5324 ?        Ss   Aug12   0:01 nginx: master process nginx
nobody   331122  0.0  0.0  90768 31776 ?        S    11:44   0:00 nginx: worker process
nobody   331123  0.0  0.0  90768 32720 ?        S    11:44   0:00 nginx: worker process
nobody   331124  0.0  0.0  90768 31776 ?        S    11:44   0:00 nginx: worker process

Конечно, некоторые инструменты не предоставляют возможности переключения на пользователя с минимальными привилегиями. Например, при запуске Redis напрямую с помощью redis-server, нам необходимо самостоятельно управлять переключением удостоверений пользователей. Итак, как же переключить удостоверения пользователей?

Давайте сначала рассмотрим пример Nginx. При запуске Nginx Linux предоставляет идентификатор «nobody». Фактически, когда кто-либо входит в систему Linux, первым полученным идентификатором пользователя является «nobody», а затем он переключается на другие обычные идентификаторы пользователя с «nobody».

Таким образом, у пользователя «nobody» обычно есть минимальные права в операционной системе. Поэтому для инструментов, не предоставляющих минимальной функциональности переключения привилегий, мы можем использовать идентификатор пользователя «nobody» для ручного переключения.

При запуске Redis с помощью redis-server мы можем использовать следующую команду для запуска redis-serverот имени пользователя «nobody» (при условии, что мы соответствующим образом настроили каталоги для журналов и PID, чтобы гарантировать возможность записи от имени пользователя «nobody»):

su -s /bin/redis-server nobody

Применяя принцип «наименьших привилегий», мы можем повысить безопасность авторизации системы Linux.

3. Механизм аудита в Linux

Как мы уже обсуждали ранее, аудит в контексте «золотых правил» в основном включает в себя ведение журнала и анализ. Итак, какие типы журналов существуют в системе Linux? В Linux информация системного журнала обычно хранится в каталоге /var/log, и некоторые приложения также регистрируют соответствующую информацию в этом каталоге. Системные журналы в основном делятся на три категории: журналы входа пользователей, журналы специальных событий и журналы процессов.

Журналы входа пользователей — это,в основном, файлы /var/log/wtmp и /var/run/utmp, в которых хранится информация, связанная с входами пользователей. Журналы входа пользователей представляют собой двоичные файлы и не могут быть просмотрены напрямую в текстовом формате, но к ним можно получить доступ с помощью таких команд, как who, users, ac, last и lastlog.

Журналы специальных событий включают в себя /var/log/secure и /var/log/message. В /var/log/secure в основном регистрируются записи, связанные с аутентификацией и авторизацией. Например, если кто-то попытается взломать SSH методом подбора пароля, этот журнал предоставит информацию о таких попытках. Файл /var/log/message поддерживается демоном syslogd, который предоставляет стандартный механизм записи специальных событий и сообщений. Другие приложения могут использовать этот демон для сообщения о специальных событиях.

Журналы процессов: Когда управление системными процессами выполняется с помощью accton, создается файл, называемый pacct, в котором записываются команды пользователя.

По умолчанию Linux использует logrotate для управления стратегиями хранения журналов (такими как ротация журналов и удаление старых журналов). Политики хранения для различных журналов можно изменить, настроив /etc/logrotate.conf.

Итак, как же нам отслеживать журналы? Я рекомендую два распространённых инструмента для анализа журналов: ELK и Zabbix. Эти инструменты можно использовать для мониторинга журналов безопасности Linux. Настроив соответствующие правила на этих аналитических платформах (например, обнаружение более трёх неудачных попыток входа по SSH), мы можем оперативно выявлять попытки вторжения со стороны хакеров и оперативно генерировать оповещения. Затем мы можем вручную проверять журналы для решения конкретных проблем.

Заключение

Безопасность систем Linux можно считать платформой с наилучшими практиками для принципа «минимальных привилегий», особенно когда несколько пользователей совместно используют и обслуживают один сервер. Правильная настройка прав доступа в таких ситуациях может быть довольно сложной. Для решения этой проблемы необходимо строго ограничить использование привилегий ROOT. Кроме того, реализация контроля доступа с помощью iptables также может обеспечить существенную защиту от уязвимостей процессов.

Помимо механизмов самозащиты системы Linux, существуют различные инструменты безопасности, обеспечивающие дополнительные уровни защиты (например, антивирусное ПО и системы обнаружения вторжений на уровне хоста).

Это перевод оригинальной статьи Every Bug I Ever Fixed Made Sense Only After I Understood These 7 Layers.

Спустя три года работы я потратил две недели на отладку причин, по которым наш API случайным образом возвращал ошибки 502. Логи были чистыми. Приложение работало исправно. Все указывало на то, что проблем нет.

Затем мимо проходил сетевой инженер и спросил: «А ты проверял, совпадает ли таймаут keepalive у балансировщика нагрузки с таймаутом сервера приложения?»

Тогда меня осенило. Я занимался отладкой не на том уровне.

Семь уровней, которые действительно имеют значение

Модель OSI — это не какое-то академическое упражнение, которое нужно заучивать наизусть для собеседований. Это ментальная модель, которая позволяет не тратить дни, копаясь не там, где нужно.

Layer 7: Application    [HTTP, DNS, SSH]
Layer 6: Presentation   [TLS, Compression]
Layer 5: Session        [Auth, Connections]
Layer 4: Transport      [TCP, UDP]
Layer 3: Network        [IP, Routing]
Layer 2: Data Link      [Ethernet, MAC]
Layer 1: Physical       [Cables, Signals]

Вот что на самом деле происходит при обращении к API:

User Request
    |
    v
[Application Layer] - Parse HTTP request
    |
    v
[Transport Layer]   - Establish TCP connection
    |
    v
[Network Layer]     - Route packets via IP
    |
    v
[Data Link Layer]   - Frame data for physical transmission
    |
    v
[Physical Layer]    - Transmit bits over wire

Уровень 7: Прикладной уровень

Здесь работает большинство разработчиков. Коды состояния HTTP, ответы API, запросы к базе данных. Но вот чего они не говорят: большинство «ошибок в приложениях» на самом деле не являются ошибками приложения.

Реальная ошибка: Пользователи жаловались, что эндпоинт загрузки файлов «не работает». API возвращал 200 OK, но файлы не отображались.

// The problematic code
func uploadHandler(w http.ResponseWriter, r *http.Request) {
    file, _, err := r.FormFile("file")
    if err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    defer file.Close()
    
    // Processing happens here
    w.WriteHeader(http.StatusOK)
    json.NewEncoder(w).Encode(map[string]string{"status": "success"})
}

В чём проблема? Большие файлы (свыше 50 МБ) тихо отклонялись nginx ещё до того, как запрос доходил до приложения. Код 200 приходил от другого запроса, который успешно обработался.

Исправление находилось на три уровня ниже:

# /etc/nginx/nginx.conf
client_max_body_size 100M;

Уровень 4: Транспортный уровень

TCP против UDP. Таймауты соединения. Исчерпание портов. Этот уровень разрушил бесчисленное количество карьер.

Классический сценарий: приложение перестаёт отвечать под нагрузкой, но показатели процессора и памяти в норме.

# Check current connections
ss -s

# Output showing the problem
TCP: 28547 (estab 1034, closed 27500, orphaned 12, timewait 27488)

27 488 соединений находятся в состоянии TIME_WAIT. Ядру не хватило доступных портов.

// Before (bad) - Creates new connection every time
func fetchUsers(userIDs []string) error {
    for _, id := range userIDs {
        resp, err := http.Get(fmt.Sprintf("https://api.example.com/user/%s", id))
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        // Process response
    }
    return nil
}

// After (good) - Reuses connections
var client = &http.Client{
    Timeout: 10 * time.Second,
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 10,
        IdleConnTimeout:     90 * time.Second,
    },
}

func fetchUsers(userIDs []string) error {
    for _, id := range userIDs {
        resp, err := client.Get(fmt.Sprintf("https://api.example.com/user/%s", id))
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        // Process response
    }
    return nil
}

Результаты теста производительности: использование пула соединений снизило время запроса с 340 мс до 12 мс под нагрузкой (1000 запросов).

Уровень 3: Сетевой уровень

Маршрутизация IP-адресов, маски подсети, разрешение DNS. Если ваш сервис не может связаться с другим сервисом, именно здесь следует искать причину.

# Trace the actual route packets take
traceroute api.internal.company.com

# Check if DNS is lying to you
nslookup api.internal.company.com

История из практики: соединения с базой данных периодически прерывались из-за таймаута. База данных работала исправно. Приложение работало исправно. Сетевая команда настаивала, что всё в порядке.

# This revealed the truth
mtr --report --report-cycles 100 db.internal.company.com

# Packet loss at hop 4: 23%

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

Уровень 2: Канальный уровень

MAC-адреса, коммутаторы, VLAN. Отладка здесь, вероятно, будет нечастой, но когда она всё-таки потребуется, всё остальное перестанет иметь значение.

В облачных средах это проявляется как «перегрузка сетевого интерфейса». Для экземпляра EC2 существует жесткое ограничение на количество пакетов в секунду, зависящее от типа экземпляра.

# Check interface stats
ip -s link show eth0

# Look for TX/RX errors or drops

Процесс отладки, который действительно работает

Перестаньте гадать. Начните мыслить уровнями.

1. Application logs clean?        -> Go down one layer
2. TCP connections normal?         -> Go down one layer  
3. Can you ping the destination?   -> Go down one layer
4. Is the cable plugged in?        -> Go outside and touch grass

Реальная сессия отладки:

# Layer 7: Application
curl https://api.example.com/health
# Returns 503

# Layer 4: Transport
telnet api.example.com 443
# Connection refused

# Layer 3: Network
ping api.example.com
# Host unreachable

# Layer 2: (Skipped in cloud)
# Resolution: DNS was returning wrong IP
nslookup api.example.com

# Pointed to decommissioned server

Паттерн, который вы увидите повсюду.

После того, как вы поймете, что такое уровни, вы начнете замечать их повсюду:

Сетевое взаимодействие в Kubernetes:

• Взаимодействие между модулями: уровень 3 (IP)
• Сервис для пода: Уровень 4 (TCP/UDP + порты)
• Входящий трафик: Уровень 7 (маршрутизация HTTP)

Проблемы с балансировщиком нагрузки:

• Connection refused: Уровень 4 (неверный порт/протокол)
• 502 Bad Gateway: Layer 7 (upstream timeout)
• Connection timeout: Уровень 3 (маршрутизация/брандмауэр)

Что изменилось для меня

Я перестал говорить «сеть не работает» и начал спрашивать «на каком уровне произошла поломка?». Я перестал отлаживать систему интуитивно и начал отлаживать методом исключения.

Та ошибка 502, что была с самого начала? У балансировщика нагрузки (уровень 7) был keepalive 60 секунд. У сервера приложений (уровень 4) — 65 секунд. Когда балансировщик нагрузки закрывал соединение, приложение всё ещё считало, что оно открыто. Следующий запрос попадал в неактивный сокет.

// The fix
server := &http.Server{
    Addr:              ":8080",
    Handler:           router,
    ReadTimeout:       15 * time.Second,
    WriteTimeout:      15 * time.Second,
    IdleTimeout:       50 * time.Second, // Less than LB's 60s
    ReadHeaderTimeout: 5 * time.Second,
}

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

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

Это перевод оригинальной статьи Open-Source DevOps Tools I Wish I Knew About Sooner.

Когда я только начинал работать в DevOps, я думал, что всё должно быть дорогим.
Мониторинг? Платный. CI/CD? Платный. Логирование? Платное.
Даже такие простые вещи, как проверка доступности, стоили денег.

Мне потребовалось несколько болезненных счетов, чтобы осознать одну вещь:

Практически у каждого крупного DevOps-инструмента есть open-source альтернатива, и многие из них на самом деле лучше.

Это те инструменты, которые я хотел бы, чтобы меня заставили изучить раньше.
Они бы сэкономили мне деньги, время и кучу нервов.

1. Portainer → Графический интерфейс Docker, о необходимости которого я даже не подозревал.

Ссылка: https://www.portinaer.io/

Раньше я управлял Docker исключительно с помощью командной строки.
Всё было хорошо… пока у меня не появились десятки контейнеров, стеков, сетей и томов.

Portainer предоставляет вам:

• Визуальная панель мониторинга
• Логи и статистика контейнеров
• Развертывание в один клик
• Шаблоны стека
• Контроль доступа пользователей

Реальный пример:
я управляю несколькими небольшими клиентскими приложениями на VPS-серверах.
Portainer превратил управление контейнерами из запутанных терминальных джунглей в удобный дашборд, где я могу перезапускать, обновлять или проверять контейнеры за считанные секунды.

2. Jenkins→ Моя первая настоящая свобода в области CI/CD

Ссылка: https://www.jenkins.io/

До появления Jenkins я в значительной степени полагался на SaaS-инструменты для непрерывной интеграции.
Они удобны, но бесплатные ограничения просто ужасны.

Jenkins предоставляет:

• Неограниченное количество пайплайнов
• Кастомные агенты
• Огромная экосистема плагинов
• Полный контроль над сборкой.

Однажды я собрал пайплайн, который:

1. Запускал тесты
2. Генерировал Docker-образы
3. Деплоил в Kubernetes
4. Отправлял уведомления в Slack

Всё работает на сервере за 10 долларов. Никаких ограничений. Никаких неожиданностей.

3. Prometheus + Grafana → Замена облачного мониторинга

Ссылки:
Prometheus: https://prometheus.io/
Grafana: https://grafana.com/

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

Prometheus обрабатывает метрики.
Grafana великолепно их визуализирует.

Где это меня выручило:
я развернул их в кластере Kubernetes — и внезапно у меня появилось:

• Панели мониторинга ЦП/памяти
• Графики состояния Pod’ов
• Пользовательские оповещения
• Метрики производительности узлов

И всё это бесплатно.

4. Alertmanager → Оповещения без оплаты

Ссылка: https://prometheus.io/docs/alerting/latest/alertmanager/

Уведомления по электронной почте… бесплатно.
Уведомления в Slack… бесплатно.
Уведомления Webhook… бесплатно.

До того, как я открыл для себя Alertmanager, я полагался на платные инструменты только для получения уведомлений.

После настройки с помощью Prometheus я смог:

• Получать оповещения о перезапуске подов.
• Отслеживать высокую загрузку ЦП.
• Выявлять сбои при развертывании

Никакого спама в SMS-сообщениях/уведомлениях, никаких скрытых платежей.

5. Loki → Инструмент логирования, который следовало использовать с самого первого дня.

Ссылка: https://grafana.com/oss/loki/

Раньше я перенаправлял логи в случайные папки и “cat”-ил их как пещерный человек.
Потом появился Loki — инструмент агрегации логов с открытым исходным кодом от Grafana.

Это как Elasticsearch, но легче и проще в использовании.

Где это помогло:
Логи срабатывали на:

• Циклических сбоях Node.js
• Ошибки подключения к базе данных
• Неожиданные ошибки 500

И всё это можно было искать в одном дашборде.

6. Argo CD → GitOps: правильный подход

Ссылка: https://argo-cd.readthedocs.io/

Если вы работаете с Kubernetes, Argo CD кажется почти волшебным инструментом.

Он за вашим Git-репозиторием и автоматически синхронизирует ваш кластер с манифестами.

Значение:

• Нет необходимости вручную выполнять kubectl apply
• Автоматический откат
• мониторинг состояния приложения
• развертывание с контролем версий

После того, как я настроил его в среде микросервисов, развертывание стало выглядеть следующим образом:

git push

Вот и всё. Argo позаботился обо всём остальном.

7. Traefik → Обратный прокси, который наконец-то стал понятным.

Ссылка: https://traefik.io/

Конфигурации NGINX заставили меня возненавидеть жизнь.
А потом я открыл для себя Traefik.

Traefik автоматически:

• Обнаруживает контейнеры
• Генерирует правила маршрутизации
• Выдает SSL-сертификаты
• Управляет балансировкой нагрузки

Пример:
я развернул несколько микросервисов с метками Docker, и Traefik мгновенно их обнаружил с действительным HTTPS-соединением — без необходимости вручную настраивать файлы конфигурации.

8. MinIO → Open-Source хранилище S3

(Бесплатное использование прекращено, но исходный код доступен по ссылке : https://github.com/minio/minio )

Ссылка: https://min.io/

AWS S3 — отличный сервис, но не всегда дешевый.

MinIO предоставляет вам:

• Объектное хранилище
• S3-совместимые API
• Высокую производительность
• Свободу самостоятельного хостинга

Я использовал его для хранения:

• Логов
• Резервных копий
• Медиафайлов
• Ресурсов приложений

С тех пор я использую MinIO для локальной разработки, тестовых окружений и даже некоторых производственных задач.

9. K9s → Терминальный интерфейс для Kubernetes

Ссылка: https://k9scli.io/

kubectl — мощный… но иногда мучительный.

K9s предоставляет вам интерактивную панель управления терминала:

• Pods
• Логи
• Доступ к оболочке
• События
• Развертывания

Это как «htop», но для вашего кластера.

Я использую его ежедневно — он значительно ускоряет отладку.

10. Gitea → Самостоятельно размещаемая альтернатива GitHub

Ссылка: https://about.gitea.com/

Для небольших команд и внутренних репозиториев GitHub может быть излишним.

Gitea предоставляет вам:

• Git-хостинг
• Issues (задачи)
• Запросы на слияние
• интеграции CI
• Использование серверов с минимальными затратами ресурсов

Я настроил её для внутреннего корпоративного проекта, и разработчики оценили, насколько быстро и удобно всё работает.

Заключительные мысли

DevOps не обязательно должен быть дорогим.
Для большинства инструментов, которые профессионалы используют ежедневно, уже существуют мощные версии с открытым исходным кодом.

А самое главное?

Использование инструментов с открытым исходным кодом заставляет вас действительно понимать, как работает ваша инфраструктура.

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

Это перевод оригинальной статьи Bash Scripting Hacks Every Developer Should Know.

Небольшие хитрости Bash, которые сэкономят часы, предотвратят катастрофы и незаметно улучшат рабочий процесс разработчика.

Введение: Bash — это навык, который вы, сами того не зная, игнорировали.

Большинство разработчиков «знают» Bash так же, как и Git: ровно столько, чтобы справляться. Несколько команд в памяти. Скрипт скопирован со Stack Overflow. Молитва перед нажатием Enter.

Но Bash — это не просто язык программирования для энтузиастов Linux или специалистов по DevOps. Это невидимая сила, стоящая за автоматизацией, отладкой, деплоями, обработкой данных и бесчисленным количеством повседневных задач. Разница между медленным разработчиком и пугающе эффективным часто сводится к тому, насколько хорошо он владеет shell’ом.

Эта статья не о запоминании малоизвестных флагов. Она о практических приемах написания скриптов на Bash — небольших идеях, оказывающих огромное влияние. Идеях, которые делают ваши скрипты безопаснее, чище и проще в обслуживании. Идеях, которые вы хотели бы увидеть много лет назад.

Давайте прокачаем вашу интуицию.

1. Всегда запускайте скрипты в «строгом режиме».

Большинство скриптов Bash завершаются с ошибкой без предупреждения. Это опасно.

Первый полезный совет, который должен знать каждый разработчик, — это включение строгого режима в начале скриптов:

set -euo pipefail

Вот что делает эта единственная строка:

• -e: В случае сбоя команды немедленно завершить работу.
• -u: Cчитает необъявленные переменные ошибкой
• -o pipefail: пайплайн считается упавшим, если любая команда завершилась с ошибкой.

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

Считайте это превращением runtime-ошибок в compile-time-ошибки для Bash.

2. Используйте "$@" вместо $* (Да, это важно)

Если ваш скрипт принимает аргументы, эта деталь может сэкономить вам часы отладки.

Всегда используйте:

"$@"

Вместо:

$*

Почему? Потому что "$@" сохраняет границы аргументов. Пробелы остаются неизменными. Имена файлов не распадаются на части. Ваш скрипт работает корректно, когда пользователи передают строки в кавычках.

Это одно из тех правил Bash, которое кажется излишне педантичным — пока из-за них не ломается что-то важное в продакшене.

3. Давайте своим переменным точные имена

В Bash нет типов, но имена — это ваша система безопасности.

Плохо:

x=10
y="file.txt"

Лучше:

MAX_RETRIES=10
INPUT_FILE="file.txt"

Почему заглавные буквы? Потому что в соглашениях Bash переменные, написанные заглавными буквами, рассматриваются как константы или параметры конфигурации. Это также помогает избежать конфликтов с переменными окружения или именами команд.

Правильно подобранные имена переменных превращают уязвимые скрипты в читаемые программы.

4. Используйте $(...) вместо обратных кавычек.

Если вы всё ещё используете обратные кавычки, пора от них отказаться.

Старый вариант:

files=`ls`

Современный вариант:

files=$(ls)

Замена команд с помощью $(...) выглядит следующим образом:

• Легче читать
• Легче вкладывается
• Менее подвержен ошибкам

Речь идёт не просто о предпочтениях в синтаксисе. Речь идёт о написании кода на Bash, который не будет создавать проблем по мере своего развития.

5. Быстро выявляйте ошибки с помощью явных сообщений об ошибках.

Если что-то пошло не так, в вашем скрипте должно быть указано, почему.

Вместо того чтобы позволять Bash загадочным образом завершать работу с ошибкой, сделайте следующее:

command || {
  echo "❌ Failed to run command"
  exit 1
}

А ещё лучше — оберните это в функцию:

die() {
  echo "Error: $1" >&2
  exit 1
}

Теперь ваши скрипты не просто терпят неудачу — они умеют доносить информацию. И вы в будущем поблагодарите себя в настоящем за эту ясность.

6. Используйте функции (даже в небольших скриптах).

Многие разработчики избегают использования функций в Bash, считая их излишними.

Нет.

Функции позволяют вам:

• Избегать дублирования
• Инкапсулировать логику
• Сделать скрипты читаемыми от начала до конца.

Пример:

cleanup() {
  rm -rf /tmp/my_app
}

Вам не нужен объектно-ориентированный Bash. Вам нужна лишь структура. Функции — это самый простой способ добиться успеха.

7. Перехватывайте сигналы как профессионал

Случалось ли вам когда-нибудь сталкиваться с тем, что скрипт оставляет незавершенные файлы после нажатия Ctrl+C?

Это потому, что вы не перехватили сигналы.

trap cleanup EXIT INT TERM

Это гарантирует, что ваша логика очистки будет выполнена даже в случае неожиданного завершения работы скрипта.

Ловушки необходимы для:

• Временных файлов
• Файлов блокировки
• Фоновых процессов

Они превращают сценарии, в которых "надеемся, ничего не пойдет не так", в сценарии, в которых "готовы к хаосу".

8. Кавычьте переменные так, будто от этого зависит ваша работа

В Bash не заключенные в кавычки переменные — это мины замедленного действия.

Плохой:

rm $file

Хороший:

rm "$file"

Если переменная $file содержит пробелы, символы шаблона или пуста, отсутствие кавычек может привести к потере данных.

Хорошее эмпирическое правило: если это переменная, заключите её в кавычки. Исключения бывают, но новичкам не следует на них полагаться.

Одна эта привычка предотвращает одни из самых страшных shell-багов, каких только можно себе представить.

9. Используйте массивы вместо строк, разделённых пробелами.

Bash поддерживает массивы. Используйте их.

Вместо:

files="a.txt b.txt c.txt"

Сделайте следующее:

files=("a.txt" "b.txt" "c.txt")

Массивы сохраняют структуру, безопасно работают с пробелами и ведут себя предсказуемо.

Циклы становятся безопаснее:

for file in "${files[@]}"; do
  echo "$file"
done

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

10. Читайте файлы построчно правильно.

Это классическая ловушка.

Неправильно:

for line in $(cat file.txt); do

Верно:

while IFS= read -r line; do
  echo "$line"
done < file.txt

Правильный подход:

• Сохраняет пробелы
• Не зависает при работе со специальными символами.
• Эффективно работает с большими файлами

Это может показаться многословным, но это единственный безопасный способ.

11. Используйте set -x для тонкой отладки

Когда скрипт работает некорректно, догадки не помогут.

Включить трассировку выполнения:

set -x

Bash выводит каждую команду перед её выполнением. Это бесценно для:

• Падений в CI
• Неожиданных значений переменных
• Логических ошибок

Вы даже можете включить его временно:

set -x
# debug section
set +x

Это встроенный отладчик Bash. Используйте его.

12. Предпочитайте [[ ... ]] вместо [ ... ]

Тестовые выражения старого образца ненадежны.

Используйте:

if [[ "$a" == "$b" ]]; then

Вместо:

if [ "$a" = "$b" ]; then

Почему?

• Без разделения слов
• Более безопасное сравнение строк
• Поддержка регулярных выражений
• Меньше проблем с кавычками

[[ ... ]] — это одно из лучших улучшений Bash. Воспользуйтесь им.

13. Используйте Here-Docs для корректного многострочного ввода.

Когда в скрипты начинают встраиваться SQL-запросы, файлы конфигурации или большие текстовые блоки, читаемость ухудшается.

Here-docs это исправляет:

cat <<EOF > config.yaml
port: 8080
env: production
EOF

Они идеально подходят для:

• Шаблонов
• Docker-конфигураций
• Встроенной документации

Читаемый Bash — это поддерживаемый Bash.

14. Делайте скрипты самодокументируемыми

Добавьте --help флаг.

Серьезно.

if [[ "$1" == "--help" ]]; then
  echo "Usage: script.sh [options]"
  exit 0
fi

Даже короткое описание использования резко повышает удобство — для коллег и для вас из будущего.

Профессиональные скрипты объясняют себя сами.

15. Относитесь к скриптам Bash как к настоящему программному обеспечению.

Это самый главный хак.

Большинство скриптов Bash не работают не потому, что Bash плох, а потому, что мы относимся к скриптам как к одноразовому коду.

Сделайте следующее:

• Используйте систему контроля версий.
• Добавляйте комментарии там, где их смысл не очевиден.
• Проводите рефакторинг по мере роста скриптов.
• Тестируйте в чистых окружениях

Bash поощряет дисциплину. Игнорируйте её, и он даст отпор.

Вывод: Bash — это инструмент, многократно увеличивающий эффективность.

Bash-скриптинг — это не про то, чтобы стать рок-звездой терминала. Bash-скриптинг — это про то, чтобы сделать вашу рабочую жизнь проще. Отправка сообщения в Slack. Загрузка случайной шутки в ваши сообщения. Поиск случайной картинки для добавления в ваши сообщения.

Вам не обязательно быть экспертом во всех аспектах Bash. Всё, что вам нужно, — это несколько полезных навыков и уверенность в их применении.

Терминал — это место, где выполняются команды, но именно там сосредоточено влияние.

Если вы достаточно хорошо освоите программирование на Bash, ваш компьютер начнет работать на вас, а не наоборот.

Это перевод оригинальной статьи SSH Cheat Sheet.

Практическое, удобное для копирования и вставки руководство по SSH для инженеров Linux, системных администраторов, администраторов баз данных и SRE-специалистов.

Часть 1 — Основы SSH (для всех)

Основные принципы использования SSH

ssh user@server_ip

Подключитесь к удалённому серверу, используя стандартный порт 22.

ssh hostname

Используются параметры из ~/.ssh/config, если они определены.

SSH с пользовательским портом и пользователем

ssh -p 2222 user@server_ip

Укажите нестандартный порт SSH.

ssh user@hostname

Войдите в систему под конкретным пользователем.

Аутентификация по SSH-ключу

Сгенерируйте SSH-ключ

ssh-keygen -t ed25519

Скопируйте открытый ключ на сервер.

ssh-copy-id user@server_ip-copy-id user@server_ip

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

Советы по работе с конфигурационными файлами SSH (настоятельно рекомендуется)

Редактировать конфигурацию:

nano ~/.ssh/config

Пример:

Host prod-db
  HostName 10.10.10.20
  User postgres
  Port 22
  IdentityFile ~/.ssh/id_ed25519

Подключение:

ssh prod-db

# Cleaner
# Faster
# Less mistakes

SSH-туннелирование и переадресация портов

Локальная переадресация портов

ssh -L 5432:localhost:5432 user@server_ip

Получите доступ к удаленной базе данных PostgreSQL так, будто он запущен локально.

Удалённая переадресация портов

ssh -R 9000:localhost:3000 user@server_ip

Предоставьте удаленному компьютеру доступ к локальному сервису.

Динамическая переадресация портов (SOCKS-прокси)

ssh -D 8080 user@server_ip

Полезно для безопасного просмотра веб-страниц и настройки прокси-серверов.

Копирование файлов с помощью SCP и RSYNC

Копирование файла на удаленный сервер

scp file.txt user@server_ip:/path/

Копирование директории

scp -r mydir user@server_ip:/path/

Более быстрый и надёжный способ (рекомендуется)

rsync -avz file.txt user@server_ip:/path/

Отладка SSH-подключений

ssh -v user@server_ip

Ещё больше деталей:

ssh -vvv user@server_ip

Проверьте, какой ключ используется:

ssh -i ~/.ssh/mykey user@server_ip

Лучшие практики безопасности

Отключить аутентификацию по паролю
Использовать SSH-ключи
Сменить стандартный порт
Использовать Fail2Ban
Ограничить доступ пользователей черезAllowUsers

Пример (sshd_config):

PasswordAuthentication no
PermitRootLogin no

Перезапустите SSH:

sudo systemctl restart sshd

Часть 2 — Объяснение параметров SSH (от новичка до продвинутого)

В этом разделе простыми словами объясняются параметры командной строки SSH. Для понимания этой части вам не потребуются предварительные знания SSH.

Напоминание о базовом синтаксисе

ssh [options] user@host

• user → имя пользователя удаленного Linux
• host → IP-адрес или имя хоста сервера
• options → параметры поведения SSH (что мы объясним ниже)

Основные и наиболее часто используемые опции (необходимо знать)

-p → Порт

ssh -p 2222 user@server

Подключение к пользовательскому SSH-порту.
Порт SSH по умолчанию = 22.
Часто меняется из соображений безопасности

Представьте, что порт — это номер двери на сервере.

-l → Имя пользователя

ssh -l postgres server_ip

Указывает, от имени какого пользователя следует войти в систему. То
же самое, что и:

ssh postgres@server_ip

-i → Файл идентификации (SSH-ключ)

ssh -i ~/.ssh/id_ed25519 user@server

Указывает SSH, какой закрытый ключ использовать.
Полезно, когда у вас несколько ключей SSH.

-v, -vv, -vvv → Подробный режим / Режим отладки

ssh -v user@server

Отображает этапы подключения.
Помогает отлаживать:

• проблемы аутентификации
• неправильные ключи
• сетевые ошибки

Чем больше v, тем больше деталей.

-F → Пользовательский файл конфигурации

ssh -F myconfig user@server

Используйте нестандартный файл конфигурации SSH.
По умолчанию используется:

~/.ssh/config

Параметры аутентификации и безопасности

-o → Пользовательская опция SSH

ssh -o StrictHostKeyChecking=no user@server

Передайте любые расширенные настройки SSH вручную.
Эквивалентно параметрам из ssh_config

Частые примеры:

-o PasswordAuthentication=no
-o ConnectTimeout=5

-A → Переадресация агента SSH

ssh -A user@server

Переадресация локальных SSH-ключей на удаленный сервер.
Используется для промежуточных серверов.

Использовать с осторожностью (риск безопасности на ненадежных серверах).

-a → Отключить переадресацию агента

ssh -a user@server

Более безопасный вариант по умолчанию:
Явно отключает переадресацию ключей.

-K → Аутентификация GSSAPI

ssh -K user@server

Используется в средах Kerberos / корпоративных средах.

Переадресация и туннелирование

-L → Переадресация локальных портов

ssh -L 5432:localhost:5432 user@server

Доступ к удалённому сервису локально.
Очень распространён в:

• PostgreSQL
• MySQL
• Веб-приложения

-R → Удалённая переадресация портов

ssh -R 8080:localhost:3000 user@server

Предоставить удалённому серверу доступ к локальному сервису

-D → Динамическая переадресация портов (SOCKS-прокси)

ssh -D 1080 user@server

Создает SOCKS-прокси.
Используется для:

• безопасного просмотр
• туннелирования трафика

-W → Переадресация стандартного ввода/вывода

ssh -W host:port user@server

В основном используется с ProxyJump.

Jump-хосты и несколько серверов

-J → Jump Host (Bastion Server)

ssh -J user@jumpserver user@target

Подключение через другой сервер.
Современная альтернатива сложным туннелям.

Управление сессией

-N → без выполнения команд

ssh -N -L 5432:localhost:5432 user@server

Только открытый туннель.
Доступ к оболочке запрещен.

-T → Отключить псевдо-TTY

ssh -T user@server

Используется в скриптах.
Нет интерактивного терминала.

-t → Принудительно включить TTY

ssh -t user@server "sudo systemctl restart postgresql"

Необходимо для sudo.

Фон и управление

-f → Фоновый режим

ssh -f -N -L 5432:localhost:5432 user@server

Запуск SSH в фоновом режиме.
Идеально подходит для туннелей.

-S → control socket

ssh -S /tmp/ssh.sock user@server

Используется при совместным использованием соединений.

-O → Команды управления

ssh -O exit user@server

Управление существующим SSH-соединением

Шифрование и алгоритмы

-c → Шифр

ssh -c aes256-gcm@openssh.com user@server

Выберите алгоритм шифрования

-m → MAC-алгоритм

ssh -m hmac-sha2-256 user@server

алгоритм аутентификации сообщений

-Q → Запрос поддерживаемых алгоритмов

ssh -Q cipher
ssh -Q mac

Выводит список поддерживаемых алгоритмов.

Параметры сетевого уровня

-B → Привязка к сетевому интерфейсу

ssh -B eth0 user@server

Принудительно направляет SSH-трафик через указанный сетевой интерфейс.

-b → Исходный адрес

ssh -b 192.168.1.10 user@server

Использует конкретный локальный IP-адрес в качестве источника соединения.

Золотое правило (совет для новичков)

Если команда SSH кажется длинной или пугающей, перенесите её в ~/.ssh/config и упростите себе жизнь.

SSH — это больше, чем просто способ подключения к серверу; это мощный инструмент для безопасного доступа, автоматизации и устранения неполадок. Если вы понимаете основы, вы можете безопасно управлять любой системой Linux. Если вы освоите параметры, вы сможете уверенно работать со сложными конфигурациями, такими как туннели, бастионные хосты и производственные среды.