📂 Шпаргалка по работе SSH в Linux!

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

На картинке — 20 этапов работы SSH: от установки TCP-соединения и проверки known_hosts до аутентификации по ключам и передачи зашифрованных данных.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Знали, что в Linux можно отключить программе доступ к сети без настройки firewall и изменения её кода?

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

Например, можно проверить, как приложение ведёт себя без сети:

sudo unshare --net -- ./myapp

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

Можно открыть отдельную оболочку и исследовать окружение:

sudo unshare --net -- bash
ip addr
ip route

По умолчанию даже интерфейс lo в новом пространстве имён не поднят.

Если нужен локальный сетевой обмен внутри него, включите loopback:

sudo unshare --net -- ip link set lo up

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

🔥 unshare --net позволяет за секунды воспроизвести отсутствие сети при тестировании приложений, не отключая интернет на всей машине. Особенно полезно для проверки автономного режима, обработки сетевых ошибок и неожиданных внешних зависимостей.

🚪 Linux Ready | #совет

🧐 Base of Knowledge — большая русскоязычная коллекция заметок, шпаргалок и руководств!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

🤔 Крутая статья попалась на Хабре: «Как ускорить дисковую подсистему с помощью bcachefs»!

В этой статье:
• Узнаете, как объединить быстрый SSD и медленный диск с помощью кэширования в bcachefs;
• Разберёте настройку Write Back и проверку производительности через fio;
• Посмотрите на реальные тесты RocksDB, где кэширование ускорило запись в 3,75 раза, а случайное чтение — в 7,74 раза.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

Как запустить процесс в отдельном сетевом пространстве Linux?

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

В линукс для этого предусмотрены network namespaces. Каждый такой namespace имеет собственные сетевые интерфейсы, таблицы маршрутизации, сокеты и ряд других сетевых настроек.

Создадим отдельное сетевое пространство:

sudo ip netns add isolated

Проверим список:

ip netns list

В выводе появится:

isolated

Теперь посмотрим сетевые интерфейсы внутри нового namespace:

sudo ip netns exec isolated ip addr

По умолчанию в нём будет только интерфейс lo, который изначально находится в состоянии DOWN.

Включим loopback:

sudo ip netns exec isolated ip link set lo up

После этого проверим его адрес:

sudo ip netns exec isolated ip addr show lo

На интерфейсе обычно уже назначен стандартный адрес 127.0.0.1/8. Включение lo позволяет использовать его для локального сетевого взаимодействия.

Попробуем выполнить запрос во внешнюю сеть:

sudo ip netns exec isolated \
  ping -c 3 1.1.1.1

Соединение не установится, поскольку в новом namespace отсутствуют внешний сетевой интерфейс и маршрут до указанного адреса. При этом сетевая конфигурация основной системы останется без изменений.

Теперь запустим внутри namespace простой HTTP-сервер. Чтобы не раздавать файлы текущего каталога, создадим отдельный пустой каталог:

mkdir -p /tmp/netns-http

Запустим сервер:

sudo ip netns exec isolated \
  python3 -m http.server 8080 \
  --bind 127.0.0.1 \
  --directory /tmp/netns-http

В другом терминале проверим, что сервер отвечает:

sudo ip netns exec isolated \
  curl -i http://127.0.0.1:8080

Сервер вернёт HTTP-ответ, поскольку клиент и сервер используют одно сетевое пространство. Для пустого каталога это будет страница со списком файлов.

Но если выполнить аналогичный запрос из основной системы:

curl http://127.0.0.1:8080

Подключиться к серверу внутри isolated не получится, если в основном namespace нет собственного listener на этом адресе и порту. Причина в том, что loopback-интерфейсы разных network namespaces независимы друг от друга.

Это позволяет запускать приложения на одинаковых адресах и портах без конфликтов между сетевыми пространствами. Проверим прослушивающие TCP-порты внутри namespace:

sudo ip netns exec isolated ss -tlnp

В выводе будет присутствовать HTTP-сервер, прослушивающий 127.0.0.1:8080.

При этом обычная команда в основной системе:

sudo ss -tlnp

Не покажет этот listener, поскольку ss просматривает сокеты текущего сетевого пространства.

Посмотрим процессы, использующие созданный namespace как основное сетевое пространство:

sudo ip netns pids isolated

Команда выведет их PID, включая процесс HTTP-сервера.

Также можно проверить сетевое пространство конкретного процесса. Подставим PID сервера из предыдущего вывода:

sudo readlink /proc/<PID>/ns/net

В результате получим идентификатор вида:

net:[4026532456]

Число в квадратных скобках идентифицирует объект namespace. У процессов в одном network namespace ссылки /proc/<PID>/ns/net указывают на один и тот же объект.

Для удаления окружения сначала остановим HTTP-сервер через Ctrl+C, затем удалим namespace:

sudo ip netns del isolated

🔥 Удаление имени namespace не завершает автоматически процессы, которые его используют. Само сетевое пространство сохраняется, пока на него существуют ссылки.

🚪 Linux Ready | #практика

В Linux можно диагностировать загрузку динамических библиотек ещё до запуска самой программы!

Если приложение падает с ошибкой cannot open shared object file, проблема часто не в отсутствии библиотеки, а в том, где именно загрузчик её ищет.

У динамического загрузчика Linux есть собственные диагностические возможности:

LD_DEBUG=libs ./myapp

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

А если нужно проверить зависимости без запуска main(), можно вызвать загрузчик напрямую:

/lib64/ld-linux-x86-64.so.2 --list ./myapp

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

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

# Посмотреть диагностические данные загрузчика
/lib64/ld-linux-x86-64.so.2 --list-diagnostics ./myapp

Последняя возможность доступна в glibc начиная с версии 2.33. Путь к загрузчику зависит от архитектуры и дистрибутива, а диагностика LD_DEBUG может быть ограничена для защищённых исполняемых файлов.

🔥 В следующий раз, когда приложение не найдёт .so, не спешите создавать симлинки и менять LD_LIBRARY_PATH. Сначала посмотрите, где загрузчик ищет библиотеку.

🚪 Linux Ready | #совет

📂 Шпаргалка по протоколу NTP!

Например, NTP позволяет синхронизировать системное время компьютеров и серверов, а временные метки T1–T4 помогают рассчитать сетевую задержку и смещение часов.

На картинке — принцип работы NTP, основные формулы, режимы синхронизации и иерархия NTP-серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

В Linux можно найти процессы, использующие конкретный порт или файл, без просмотра полного списка открытых дескрипторов!

Для этого есть fuser из пакета psmisc. Он удобен, когда сервис не запускается из-за занятого порта:

sudo fuser -v -n tcp 8080

Команда покажет процессы, связанные с TCP-портом 8080. А если нужно узнать, кто использует файл или каталог:

sudo fuser -v /var/log/myapp.log

Есть и более интересный сценарий: выяснить, какие процессы мешают размонтировать файловую систему:

sudo fuser -vm /mnt/data

Здесь -m ищет процессы, использующие файлы на той же файловой системе, что и указанный путь. Это полезно при ошибке target is busy.

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

🚪 Linux Ready | #совет

В Linux можно передать уже открытый сетевой сокет другому процессу без повторного открытия порта!

Этот механизм называется socket activation. Его поддерживает systemd: он сам открывает порт и передаёт готовый файловый дескриптор запускаемому сервису.

Например, можно создать сокет для приложения:

# /etc/systemd/system/myapp.socket
[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

После включения сокета systemd начинает слушать порт, даже если приложение ещё не запущено:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.socket

Когда приходит подключение, ядро ставит его в очередь, а systemd запускает myapp.service и передаёт ему слушающий сокет. Для работы нужен соответствующий unit-файл и приложение с поддержкой socket activation (например, через LISTEN_FDS). Обычный сервер, самостоятельно вызывающий bind(), без адаптации не подойдёт.

Проверить состояние можно так:

systemctl status myapp.socket
systemctl list-sockets

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

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

🚪 Linux Ready | #совет

✍️ linux-book — большое руководство по Linux на русском языке!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Как диагностировать проблемы с MTU и Path MTU Discovery в линукс?

TCP-соединение установилось, мелкие пакеты проходят, а передача данных зависает? Возможно, поймали PMTU black hole: крупные пакеты с DF отбрасываются, а ICMP Fragmentation Needed не доходит до отправителя. Такое встречается с VPN, GRE и VXLAN.

Начнём с MTU интерфейса:

ip -d link show dev eth0

Например:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Но MTU 1500 на интерфейсе ещё не означает, что пакеты такого размера пройдут весь маршрут.

Проверим маршрут:

ip -4 route get 203.0.113.10

Теперь отправим IPv4-пакет размером 1500 байт с запретом фрагментации:

ping -4 -M do -s 1472 -c 3 203.0.113.10

Размер: 1472 байта данных + 8 байт ICMP + 20 байт IPv4. Если пакет не проходит, попробуем 1400 байт:

ping -4 -M do -s 1372 -c 3 203.0.113.10

Если меньшие пакеты проходят, а большие нет — есть повод проверить Path MTU.

Отсутствие ответа на ping ещё не доказывает проблему с MTU. Кроме того, -M do учитывает уже известный ядру PMTU. Для проверки в обход этого ограничения можно использовать:

sudo ping -4 -M probe -s 1472 -c 3 203.0.113.10

Для дополнительной диагностики запустим:

tracepath -n 203.0.113.10

Утилита может показать обнаруженное ограничение:

pmtu 1400

Результат зависит от прохождения ICMP. В Debian/Ubuntu tracepath доступен в пакете iputils-tracepath.

Теперь посмотрим, какой PMTU известен ядру:

ip -4 route get 203.0.113.10

Если информация сохранена, вывод может содержать:

cache expires 420sec mtu 1400

Для действующего TCP-соединения проверим MSS и PMTU:

ss -tin dst 203.0.113.10

Например:

mss:1360 pmtu:1400

При стандартных 20-байтных заголовках IPv4 и TCP получаем MSS 1360. Фактические значения могут отличаться.

В линукс есть и встроенный механизм TCP MTU probing, который помогает при проблемах с определением MTU. Проверим его состояние:

sysctl net.ipv4.tcp_mtu_probing

Возможные значения:

0 — отключён
1 — включается при обнаружении проблемы
2 — включён постоянно

Сохраним исходное значение и временно включим механизм:

original=$(sysctl -n net.ipv4.tcp_mtu_probing)
sudo sysctl -w net.ipv4.tcp_mtu_probing=1

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

Вернём исходное значение:

sudo sysctl -w net.ipv4.tcp_mtu_probing="$original"

Механизм работает только для TCP в соответствующем сетевом пространстве имён и не заменяет правильную настройку MTU туннелей. Все проверки рассчитаны на IPv4. В IPv6 для обнаружения ограничений используется ICMPv6 Packet Too Big.

Адрес 203.0.113.10 приведён для примера. Замените его на адрес доступного узла, где воспроизводится проблема, а eth0 — на свой интерфейс.

🔥 PMTU black hole — одна из причин, почему TCP-соединение есть, а нормальной передачи данных нет. Проверка DF-пакетов, tracepath, PMTU и MSS помогает найти ограничение на маршруте, особенно в сетях с VPN и туннелями.

🚪 Linux Ready | #практика

❤️ Необычная и крайне интересная статья на Хабре: «Пустили ботов по SSH на фейковый сервер с четырьмя H100: что они там делали»!

В этой статье:
• Узнаете, как с помощью Python и Cowrie создать SSH-ловушку, имитирующую мощный сервер с четырьмя NVIDIA H100;
• Посмотрите, что делали атакующие боты после входа: меняли пароли, добавляли SSH-ключи и пытались установить майнеры;
• Разберёте результаты первых 12,5 часов эксперимента — 1 846 подключений и более 1 500 команд — и способы защиты SSH от подобных атак.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

В Git можно переносить незавершённые изменения между проектами или рабочими деревьями без коммитов и копирования файлов вручную!

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

git diff > changes.patch

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

Перед применением полезно проверить, получится ли внести изменения:

git apply --check changes.patch

Если проверка прошла успешно, применяем:

git apply changes.patch

А если нужно перенести и изменения, уже добавленные в индекс, используйте:

git diff HEAD > changes.patch

Важно: новые неотслеживаемые файлы в такой патч автоматически не попадут.

🔥 git diff вместе с git apply — удобный способ переносить локальные правки между рабочими деревьями, тестовыми окружениями и копиями проекта без промежуточных коммитов.

🚪 Linux Ready | #совет