Linux Ready | DevOps

Работаем с SSH-конфигурацией: избавляемся от длинных команд подключения!

Если приходится регулярно подключаться к нескольким серверам, использовать разные SSH-ключи, нестандартные порты или подключаться через промежуточный сервер, длинные команды ssh быстро становятся неудобными. Для этого существует пользовательский файл конфигурации ~/.ssh/config, который позволяет хранить все параметры подключения в одном месте.

Если каталог ~/.ssh еще не существует, сначала создайте его и установите правильные права доступа:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

После этого SSH-клиент будет автоматически читать файл ~/.ssh/config при каждом подключении. Достаточно один раз описать нужные серверы, и в дальнейшем подключение станет значительно проще.

Например, добавим конфигурацию для рабочего сервера:
Host prod
HostName 192.168.1.10
User deploy
Port 22
IdentityFile ~/.ssh/id_ed25519

Теперь вместо длинной команды:
ssh -i ~/.ssh/id_ed25519 deploy@192.168.1.10

достаточно выполнить:
ssh prod

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

Точно так же можно сохранить параметры подключения к серверу с нестандартным SSH-портом:
Host backup
HostName backup.example.com
User admin
Port 2222
IdentityFile ~/.ssh/id_backup

После этого для подключения не нужно помнить номер порта или каждый раз использовать параметр -p:
ssh backup

Еще одна полезная возможность — использовать отдельные SSH-ключи для разных сервисов. Например, для GitHub:
Host github.com
User git
IdentityFile ~/.ssh/github
IdentitiesOnly yes

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

Если нужный сервер доступен только через промежуточный сервер (bastion или jump-хост), это тоже легко настраивается:
Host internal
HostName 10.10.0.15
User admin
ProxyJump bastion

Host bastion
HostName bastion.example.com
User jump

После этого достаточно выполнить всего одну команду:
ssh internal

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

Чтобы SSH быстрее обнаруживал потерю соединения и не оставлял зависшие сессии при проблемах с сетью, можно добавить общие параметры:
Host *
ServerAliveInterval 30
ServerAliveCountMax 3

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

Если хотите убедиться, какие именно параметры SSH использует для конкретного подключения после применения всех правил из конфигурации, выполните:
ssh -G prod

Команда покажет итоговую конфигурацию: имя пользователя, адрес сервера, порт, используемый ключ и все остальные параметры после обработки файла ~/.ssh/config. Это один из самых удобных способов проверить, что конфигурация настроена именно так, как вы ожидаете.

🔥 Файл ~/.ssh/config значительно упрощает работу с большим количеством серверов. Он избавляет от длинных команд подключения, позволяет хранить параметры в одном месте, использовать разные SSH-ключи, ProxyJump, нестандартные порты и множество других возможностей OpenSSH, которые делают ежедневную работу администратора или разработчика гораздо удобнее.

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

Знали, что отдельной команде можно выдать собственные /tmp и /var/tmp, не создавая контейнер?

Для этого у systemd есть свойство PrivateTmp:
systemd-run --user --pipe \
-p PrivateTmp=yes \
bash

Запущенная оболочка получает отдельные временные каталоги. Файлы, созданные программой в /tmp и /var/tmp, не будут видны через обычные /tmp и /var/tmp хоста.

Это удобно при запуске сборок, тестов и сторонних инструментов, которые создают множество временных файлов:
systemd-run --user --pipe \
-p PrivateTmp=yes \
npm test

После завершения временного unit systemd освобождает связанное с ним приватное пространство временных файлов.

При этом это не полноценная песочница: PrivateTmp=yes изолирует именно /tmp и /var/tmp, а остальные доступные программе пути сам по себе не скрывает.

🔥 PrivateTmp позволяет одной командой изолировать временные файлы конкретной задачи без Docker и ручного создания mount namespace.

🚪 Linux Ready | #совет

Резервное копирование Linux-сервера через rsync с сохранением прав и атрибутов!

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

Базовый вариант синхронизации:
rsync -av /data/ /backup/data/

Для серверных данных обычно используют расширенный режим:
rsync -aHAX /srv/ /backup/srv/

Ключ -a сохраняет структуру каталогов, права, владельцев, группы, время изменения и символические ссылки. -H сохраняет жёсткие ссылки, -A переносит ACL, а -X сохраняет расширенные атрибуты.

При переносе между серверами важно сохранить исходные UID и GID, чтобы права доступа остались корректными:
rsync -aHAX --numeric-ids -e ssh /srv/ backup@10.0.0.20:/backup/server/

Для зеркального копирования используют параметр --delete. Он удаляет в резервной копии файлы, которых больше нет в источнике, поэтому перед применением стоит проверить изменения:
rsync -aHAX --delete --dry-run --itemize-changes /srv/ /backup/srv/

rsync часто применяется для миграции серверов и переноса больших объёмов данных через SSH:
rsync -aHAX -e ssh /srv/ backup@server:/backup/

Если канал передачи ограничен по скорости, можно задать максимальную пропускную способность:
rsync -aHAX --bwlimit=50M /srv/ backup@server:/backup/

При передаче больших файлов после разрыва соединения можно сохранить частично переданные данные:
rsync -aHAX --partial --progress /images/ backup@server:/backup/images/

Параметр --append-verify следует использовать осторожно. Он подходит для случаев, когда файл только дописывается и не изменяется в уже записанной части.

Для создания нескольких ежедневных копий часто используют --link-dest. Неизменившиеся файлы будут представлены жёсткими ссылками и не займут дополнительное место:
rsync -aHAX --link-dest=/backup/latest /data/ /backup/$(date +%F)/

Пример структуры хранения:
/backup/
├── 2026-08-13/
├── 2026-08-14/
├── 2026-08-15/
└── latest -> 2026-08-15/

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

При резервном копировании всей системы обычно исключают виртуальные файловые системы Linux:
rsync -aHAX \
--exclude=/proc \
--exclude=/sys \
--exclude=/dev \
--exclude=/run \
/ /backup/system/

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

Автоматический запуск можно настроить через cron:
0 3 * * * /usr/bin/rsync -aHAX --delete --log-file=/var/log/rsync-backup.log /srv/ /backup/srv/

Проверить различия между источником и копией без изменения данных можно через --dry-run:
rsync -aHAX --dry-run /srv/ /backup/srv/

Для проверки содержимого через контрольные суммы используется параметр --checksum:
rsync -aHAX --checksum --dry-run /srv/ /backup/srv/

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

rsync хорошо подходит для миграции серверов, синхронизации каталогов и создания файловых резервных копий. Однако это инструмент синхронизации, а не полноценная backup-система.

🔥 Он не гарантирует согласованное состояние работающих баз данных. Для MySQL, PostgreSQL и других сервисов обычно используют дампы, snapshots файловой системы или предварительную остановку приложения перед копированием. Надёжность резервной копии определяется не фактом её создания, а успешным восстановлением из неё.

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

Как namei помогает быстро найти причину Permission denied!

Наверняка у вас была такая ситуация: файл существует, права на него вроде бы выставлены правильно, но вместо доступа получаете:
Permission denied

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

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

Быстро найти проблемное место помогает утилита namei. Например:
namei -l /var/www/app/storage/logs/app.log

Пример вывода:
f: /var/www/app/storage/logs/app.log
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-x--- root www-data www
drwxr-xr-x app app app
drwx------ app app storage
drwxr-xr-x app app logs
-rw-r--r-- app app app.log

namei разбивает путь на отдельные компоненты и показывает права, владельца и группу для каждого каталога и самого файла. Благодаря этому не нужно вручную выполнять ls -ld для каждого каталога на пути — вся цепочка сразу перед глазами.

Но стоит помнить, что для каталогов право x означает возможность пройти через каталог и обратиться к объекту по известному имени, а не выполнить его. Поэтому даже если файл имеет права 644, процесс всё равно получит Permission denied, если хотя бы на одном из родительских каталогов отсутствует право x. Например, каталог:
drwx------ app app storage

доступен только владельцу. Поэтому процесс, запущенный от имени www-data, не сможет открыть файл внутри этого каталога, даже если сам файл доступен на чтение.

Чтобы убедиться, что проблема действительно в правах доступа, попробуйте открыть файл от имени пользователя, под которым фактически работает приложение:
sudo -u www-data cat /var/www/app/storage/logs/app.log

И не забудьте проверить, от какого пользователя действительно запущен процесс, который обращается к файлу. Например, для nginx:
ps -o user,group,pid,cmd -C nginx

Если права выглядят корректными, проверьте ACL. Желательно не только у файла, но и у каталогов на пути к нему:
getfacl /var/www/app/storage
getfacl /var/www/app/storage/logs
getfacl /var/www/app/storage/logs/app.log

Если и здесь всё в порядке, обратите внимание на SELinux или AppArmor — они тоже нередко становятся причиной Permission denied.

🔥 namei -l — одна из тех команд, которые экономят много времени при поиске причин Permission denied. Вместо проверки каждого каталога вручную вы сразу видите весь путь и права доступа на каждом уровне.

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

Как записать терминальную сессию Linux для последующего анализа с помощью script?

Во время диагностики проблемы или разбора инцидента часто нужно сохранить не только команды, но и весь процесс работы в терминале. История оболочки показывает только введённые команды, а > или tee не сохраняют полноценную интерактивную работу приложений. Для таких задач используется утилита script из пакета util-linux.

Она создаёт псевдотерминал (PTY) и записывает вывод терминальной сессии: результаты выполнения команд, вывод программ, работу интерактивных приложений и управляющие последовательности терминала. При необходимости отдельно можно сохранить и поток ввода пользователя. Начать запись:
script session.log

После запуска открывается новая интерактивная shell-сессия через PTY, а происходящее в терминале сохраняется в файл session.log. Завершить запись:
exit

или:
Ctrl+D

Если нужно сохранить интервалы времени между действиями для последующего воспроизведения:
script --log-timing=session.time session.log

Воспроизведение:
scriptreplay --timing=session.time session.log

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

Можно отдельно сохранить ввод пользователя, вывод терминала и временные интервалы:
script \
--log-in=input.log \
--log-out=output.log \
--log-timing=timing.log

Будут созданы три файла: input.log — поток ввода пользователя, output.log — вывод терминала и timing.log — временные интервалы между событиями.

Важно: --log-in сохраняет именно ввод пользователя, поэтому туда могут попасть пароли, токены и другие чувствительные данные. Если нужен только вывод терминала:
script --log-out=session.log

Проверить журнал:
less session.log

Поиск ошибок:
grep "ERROR" session.log

Если лог содержит ANSI escape sequences или управляющие символы терминала, отображение может выглядеть некорректно. Так как script работает через PTY, это запись терминальной сессии, а не полноценный аудит действий пользователя. Для безопасности и контроля действий обычно используют специализированные инструменты, например auditd или системы session recording.

🔥 script — простой способ сохранить интерактивную терминальную сессию Linux без изменения привычного рабочего процесса. PTY позволяет получить один из самых полных вариантов сохранения контекста для анализа и разбора инцидентов.

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