💡 Полезные Советы

Linux: Почему sudo echo >> не работает и как писать в системные файлы правильно

19.01.26
20

Вы наверняка сталкивались с этой классической ошибкой новичка. Вы пытаетесь добавить строку в конфиг, но получаете Permission denied, даже используя sudo.

Как делать не надо

Допустим, мы хотим добавить репозиторий:

sudo echo "deb http://nginx.org/packages/mainline/ubuntu/ jammy nginx" >> /etc/apt/sources.list.d/nginx.list

Результат: bash: /etc/apt/sources.list.d/nginx.list: Permission denied

Почему так происходит?

Дьявол кроется в порядке выполнения команд оболочкой:

  1. Оболочка сначала обрабатывает оператор >>.
  2. Именно оболочка (bash/zsh), а не sudo, пытается открыть файл на запись.
  3. Оболочка запущена от вашего текущего пользователя (не root), поэтому прав на запись нет.

  4. Команда sudo применяется только к echo, но не к самому процессу записи в файл.

Решение: Команда tee

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

Правильный синтаксис:

echo "Hello world" | sudo tee -a /tmp/testfile.txt
  • | (пайп) передает текст команде справа.

  • sudo запускает tee с правами суперпользователя.

  • -a (append) - критически важный флаг. Он добавляет текст в конец файла. Без него tee перезапишет файл целиком!

Мини-демонстрация

Попробуем на безопасном примере:

# Пишем
echo "Hello world" | sudo tee -a /tmp/testfile.txt

# Проверяем
cat /tmp/testfile.txt

Вывод: Hello world

Продвинутый уровень: Полезные сценарии

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

1. Безопасное добавление нескольких строк (Here-Doc)

Если нужно записать целый блок конфига, не нужно делать десять echo. Используйте конструкцию EOF в связке с tee:

cat <<EOF | sudo tee -a /etc/sysctl.conf
# Улучшение сетевых настроек
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
EOF

Это чисто, читаемо и выполняется одной транзакцией, не перезаписывает файл.

2. Удаление или замена строк (sed)

Для удаления строк перенаправление не нужно, так как sed умеет редактировать файлы "на месте" (in-place).

Удалить конкретную строку (например, с ошибочным репозиторием):

# Удаляет все строки, содержащие "google-chrome"
sudo sed -i '/google-chrome/d' /etc/apt/sources.list

Заменить одно значение на другое:

# Заменяет "PermitRootLogin yes" на "PermitRootLogin no"
sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

Важно: Флаг -i изменяет исходный файл. Всегда делайте бэкап перед запуском!

3. Обработка данных и запись в защищённый файл (ss + awk + tee)

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

Пример: Сохранить список портов, на которых слушают сервисы.

# awk фильтрует данные, а tee записывает их с правами root
ss -tuln | awk '/LISTEN/ {print $5}' | sudo tee /var/log/active_ports.log > /dev/null

Заметка: > /dev/null в конце нужен, если вы не хотите, чтобы tee дублировал результат вам в консоль.

4. Как делать бэкап "на лету"

При изменении конфигов через sed или tee хорошим тоном считается создание резервной копии.

С sed это очень просто - добавьте расширение после флага -i:

# Создаст файл /etc/hosts.bak перед изменением
sudo sed -i.bak 's/old-ip/new-ip/' /etc/hosts

Где это пригодится?

  • Apt: Добавление репозиториев в /etc/apt/sources.list.d/

  • Config: Изменение настроек в /etc/nginx/, /etc/apache2/

  • System: Тюнинг ядра в /etc/sysctl.conf

  • Security: Добавление лимитов в /etc/security/limits.conf

  • Keys: Запись бинарных ключей: cat key.gpg | sudo tee /usr/share/keyrings/app.gpg

Почему dnf не находит ncdu, htop, jq в AlmaLinux/RHEL - и как это исправить (EPEL)

18.01.26
27

Частая ситуация: вы настраиваете свежий сервер на AlmaLinux, Rocky Linux или RHEL, пытаетесь установить привычные утилиты (например, ncdu для анализа диска или htop), но получаете ошибку:

Error: Unable to find a match: ncdu

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

Почему ncdu "нет" в AlmaLinux?

На самом деле ncdu существует и отлично работает на этих системах. Проблема кроется в философии RHEL-подобных дистрибутивов:

  1. Минимализм базы: Официальные репозитории (BaseOS, AppStream) содержат только самый необходимый и максимально стабильный софт, поддерживаемый вендором.

  2. Сообщество: Большинство "удобных" инструментов администрирования (ncdu, htop, nload, jq, screen) вынесены в отдельный репозиторий - EPEL (Extra Packages for Enterprise Linux).

  3. Результат: Пока EPEL не подключен, пакетный менеджер просто не видит эти программы.

Решение: Подключение EPEL

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

1. Устанавливаем репозиторий EPEL:

sudo dnf install epel-release -y

2. Обновляем кэш (необязательно, но полезно):

sudo dnf makecache

3. Устанавливаем ncdu: Теперь команда сработает без ошибок:

sudo dnf install ncdu -y

Как проверить, что всё получилось?

Вы можете проверить информацию о пакете и убедиться, что он берется именно из EPEL:

dnf info ncdu

В выводе вы увидите строку Repository : epel и версию программы (например, 1.17 или новее).

Совет

Если вы часто настраиваете серверы, добавьте установку epel-release в свой базовый скрипт первоначальной настройки. Это сэкономит время при установке большинства популярных утилит для мониторинга и администрирования.

 

Как часто нужно обновлять SSH ключи?

17.01.26
27

Коротко: большинство экспертов рекомендуют менять SSH‑ключи раз в 6 - 12 месяцев, но частота зависит от уровня риска и требований безопасности. Современные рекомендации подчёркивают, что ключи нельзя оставлять "вечными", потому что со временем они превращаются в скрытый риск для инфраструктуры.

1. Для личных проектов и своего сервера

Рекомендуемая частота: Раз в 1 год (или даже реже).

Для личного использования (если вы единственный администратор) частая смена ключей может создать больше проблем, чем пользы (например, риск потерять доступ при неправильной замене). Главное правило: Меняйте ключ немедленно, если:

  • Вы потеряли ноутбук или флешку с ключом.

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

  • Вы случайно "засветили" приватный ключ (выложили на GitHub, отправили в чат и т.д.).

2. Для работы и продакшна (Лучшая Практика)

Рекомендуемая частота: Раз в 3-6 месяцев.

В корпоративной среде риски выше.

  • Стандарт PCI DSS (для работы с картами), из-за него многие корпоративные регламенты требуют ротацию каждые 90 дней (корпоративной среде существует огромная разница между "что написано в стандарте" и "что требуют аудиторы / безопасники на местах".)

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

PCI DSS (Payment Card Industry Data Security Standard) - это "золотой стандарт" безопасности для любой организации, которая хранит, обрабатывает или передает данные банковских карт (Visa, Mastercard, МИР).

SSH - это главная дверь для управления сервером. Если ваш сервер имеет отношение к платежам или картам, то настройки SSH становятся объектом пристального внимания аудиторов PCI DSS.

Даже если вы не банк, требования PCI DSS полезно знать, потому что это готовая инструкция "как сделать действительно безопасно".

1. Запрет прямого входа root (Требование 8.6)

  • Что требует стандарт: Каждое действие на сервере должно быть привязано к конкретному человеку. Если все заходят под общим логином root, то в логах будет видно «root удалил базу данных», но непонятно, кто именно это был - Вася или Петя.

  • Ваша ситуация: Вы только что создали личного пользователя (h...) и отключили PermitRootLogin. Это полное соответствие стандарту. Теперь в логах будет видно: "Пользователь h... повысил права до root и удалил базу".

2. Запрет простых паролей и использование криптографии (Требование 2.3)

  • Что требует стандарт: Для административного доступа через интернет нужно использовать сильную криптографию. Передача паролей в открытом виде запрещена.

  • Ваша ситуация: SSH сам по себе шифрует трафик. А отключение входа по паролю (PasswordAuthentication no) и переход на ключи - это лучшая практика (Best Practice), которую аудиторы очень любят.

3. Регулярная смена ключей (Требование 3.6.4)

  • Что требует стандарт: Криптографические ключи (Ключи шифрования данных (Data Encryption Keys)) должны меняться по расписанию (обычно каждые 90 дней), а старые - уничтожаться.

  • Что это: Это ключи, которыми шифруется сама база данных с номерами карт. Если хакер украдет этот ключ и дамп базы, он сможет прочитать номера карт.

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

4. Не использовать "дефолтные" настройки (Требование 2.1)

  • Что требует стандарт: Нельзя использовать пароли и настройки, которые идут "из коробки" (vendor-supplied defaults).

  • Ваша ситуация: Вы уже изменили порт (если меняли?), отключили рута, создали своего юзера. Вы уже не используете дефолт.

Стандарт PCI DSS настоятельно рекомендует (а версия 4.0 требует) двухфакторную аутентификацию (MFA) даже для администраторов. PCI DSS не предписывает конкретный метод, например "SSH‑ключ + код Google Authenticator". Он требует наличия MFA, а конкретная реализация остаётся на усмотрение организации!

3. Критические ситуации (Менять немедленно)

В этих случаях расписание не имеет значения - нужно действовать сразу:

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

  2. Скомпрометированное устройство. Логика "я почистил компьютер антивирусом, значит всё в порядке" здесь не работает. Вирусы (трояны, стилеры) настроены искать именно файлы в папке .ssh. Как только вирус попадает на компьютер, он мгновенно копирует эти файлы и отправляет их злоумышленнику. Вы можете возразить: "Но у меня ключ защищен паролем (passphrase)!". Если устройство скомпрометировано, скорее всего, на нем работал кейлоггер (программа, записывающая нажатия клавиш). Когда вы вводили пароль, чтобы разблокировать ключ, хакер получил и файл ключа, и пароль к нему.

  3. Смена алгоритмов шифрования. Если вы использовали старые ключи RSA-1024 или DSA (которые сейчас считаются слабыми), их нужно срочно заменить на современные Ed25519 или RSA-4096.

Частая ошибка при обновлении

Многие думают, что создание нового ключа автоматически отменяет старый. Это не так. SSH-сервер пускает по списку ключей. Если вы добавите новый ключ, но забудете удалить строку со старым ключом из файла ~/.ssh/authorized_keys, то старый ключ продолжит работать.

Правильный алгоритм ротации:

  1. Сгенерировать новую пару ключей (ssh-keygen -t ed25519).

  2. Добавить новый публичный ключ на сервер.

  3. Проверить вход с новым ключом.

  4. Удалить старый публичный ключ из файла authorized_keys на сервере.

  5. Удалить старый приватный ключ с локального компьютера.

 

Как обновить флэшку с Ventoy без потери данных?

17.01.26
48

Одной из главных особенностей Ventoy является модульность. Загрузчик на флешке можно обновить до свежей версии (например, чтобы получить поддержку новых ISO), не затрагивая сами образы и ваши документы на накопителе.

Пошаговый процесс:

  1. Скачайте архив с новой версией программы и распакуйте его.

  2. Вставьте вашу загрузочную флешку с Ventoy в компьютер.

  3. Запустите файл Ventoy2Disk.exe.

  4. Программа автоматически определит накопитель. Обратите внимание на строки версии:

    • В пакете (In Package): Версия, которую вы скачали (новая).

    • Устройство (In Device): Версия, установленная сейчас на флешке (старая).

  5. Нажмите кнопку Обновить (Update).

⚠️ Важно: Будьте внимательны! Кнопка Установить (Install) полностью отформатирует флешку и удалит все данные. Для сохранения файлов нажимайте только Обновить (Update).

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

Настройка поведения питания и сессий в Linux через logind.conf

17.01.26
50

В Linux за управление входом пользователей и реакцию на события питания (закрытие крышки ноутбука, нажатие кнопки включения) отвечает компонент systemd-logind. Его конфигурационный файл находится по адресу /etc/systemd/logind.conf.

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

Шаг 1. Открываем файл Для редактирования потребуются права суперпользователя (root). Откройте терминал и введите:

sudo nano /etc/systemd/logind.conf

Вы увидите список параметров. Обратите внимание: все строки начинаются с символа # (закомментированы). Это значит, что действуют настройки по умолчанию. Чтобы изменить настройку, нужно убрать # и поменять значение.

Шаг 2. Самые полезные параметры

Вот список настроек, которые меняют чаще всего:

  • HandleLidSwitch - Реакция на закрытие крышки ноутбука.

    • suspend - уйти в сон (по умолчанию).

    • ignore - ничего не делать (идеально, если ноутбук используется как сервер с закрытой крышкой).

    • lock - заблокировать экран.

  • HandlePowerKey - Реакция на нажатие кнопки питания на корпусе.

    • poweroff - выключение.

    • ignore - отключить кнопку (защита от детей, котов или случайных нажатий).

  • KillUserProcesses - Управление фоновыми процессами.

    • yes - при выходе из системы (logout) убивать все процессы пользователя.

    • no - оставлять процессы (tmux, screen, nohup) работающими (полезно для серверов).

Шаг 3. Готовые примеры

Сценарий 1: "Домашний сервер из ноутбука" Задача: Ноутбук должен продолжать работать, качать торренты или держать сайт, даже если крышка закрыта.

[Login]
HandleLidSwitch=ignore

Сценарий 2: "Защита от кота" Задача: Кот любит спать на системном блоке и случайно нажимает кнопку выключения. 

[Login]
HandlePowerKey=ignore

(Примечание: Удержание кнопки на 5-10 секунд всё равно выключит компьютер аппаратно).

Сценарий 3: "Удаленная работа" Задача: Вы запускаете долгие скрипты через SSH и хотите, чтобы они не падали при разрыве соединения.

[Login]
KillUserProcesses=no

Шаг 4. Применение настроек Чтобы изменения вступили в силу, не обязательно перезагружать компьютер. Достаточно перезапустить сервис:

sudo systemctl restart systemd-logind

Важно: Перезапуск этого сервиса может на секунду прервать работу графического интерфейса или выбросить вас на экран входа в систему. Сохраните данные перед вводом команды.

Дополнительно: Как включить консоль на 7-м экране (F7)

По умолчанию в Linux активно 6 текстовых консолей (TTY1–TTY6), а на F7 обычно находится графический интерфейс. Если вы хотите использовать F7 как еще одну текстовую консоль, сделайте следующее:

  1. Откройте конфиг:

  2. sudo nano /etc/systemd/logind.conf
  3. Найдите и раскомментируйте (уберите #) эти строки, изменив значения:
  4. [Login]
    NAutoVTs=7
    ReserveVT=7
  5. Примените изменения:
  6. sudo systemctl restart systemd-logind

Как сбросить пароль Linux, если стандартные методы не работают (SELinux + Read-only)

15.01.26
51

Стандартные инструкции с YouTube не всегда помогают, особенно когда имеешь дело со сложными конфигурациями. Статей по теме не нашлось, а стандартный вход через init=/bin/sh приводил либо к зависанию системы при попытке загрузки (exec init=/sbin/init), либо к ошибкам в графическом интерфейсе в духе "Извините, но сейчас это невозможно сделать".

Потратив 2 часа на эксперименты, я нашел рабочий алгоритм. Проблема крылась в SELinux и правах доступа, которые блокировали изменение пароля, выдавая ошибку Authentication token manipulation error.

Ниже - пошаговая инструкция для "тяжелых" случаев.

Предыстория: Вы забыли все пароли, включая root

Симптомы проблемы

  • Вы сбросили пароль через passwd, но система выдает Authentication token manipulation error.
  • Файловая система находится в режиме "Только чтение" (Read-only).
  • При попытке входа в GUI вы видите ошибку о недоступности входа или пароль не подходит.

Инструкция по восстановлению

Шаг 1. Вход в режим редактирования загрузки

  1. Перезагрузите компьютер.
  2. Как только появится меню загрузки GRUB (черный экран со списком систем), быстро нажмите клавишу e (Edit).
  3. Найдите строку, которая начинается с linux, linux16 или linuxefi.
  4. В конце этой строки (через пробел) допишите:

    init=/bin/sh
  5. Нажмите Ctrl + X (или F10), чтобы загрузиться в консоль.

Шаг 2. Подготовка файловой системы

По умолчанию диск смонтирован в режиме Read-only, поэтому изменения не сохранятся. Исправим это:

mount -o remount,rw /

Проверка (должно быть rw в строке вашего диска):

mount | grep root

Шаг 3. "Ручной взлом" пользователя

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

Этап А: Убираем хеш пароля

Откройте файл теней:

nano /etc/shadow

(Если nano нет, придется использовать vi).

Найдите строку нужного пользователя (например, cdr или root). Строка выглядит примерно так:
cdr:$6$hG7s... (длинный набор символов) ...:18416...

Вам нужно стереть всё, что находится между первым и вторым двоеточием. Должно стать:

cdr::18416...

Сохраните файл (Ctrl+O -> Enter) и выйдите (Ctrl+X).

Этап Б: Отключаем проверку "x" (Обязательно для надежности)

Откройте файл пользователей:

nano /etc/passwd

Найдите строку пользователя: cdr:x:1000:1000...
Удалите букву x после имени.

Должно стать:

cdr::1000:1000...

** Примечание: Если не помните пользователя, делайте это для пользователя root — под ним можно всё.

Сохраните и выйдите. Перезагрузитесь.

Шаг 4. Самый важный шаг (SELinux)

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

На большинстве систем:
•     GUI - Ctrl+Alt+F1 или Ctrl+Alt+F2
•     текстовые консоли - Ctrl+Alt+F3-F6

Ctrl+Alt+F7 - это старый Xorg-подход, сейчас не всегда работает.

Именно здесь большинство инструкций терпят неудачу. Поскольку мы редактировали системные файлы (shadow и passwd) вручную через редактор, метки безопасности SELinux сбились. Система думает, что файлы повреждены злоумышленником, и блокирует любые операции с паролями.

Восстановите контекст безопасности командами:

restorecon -v /etc/shadow
restorecon -v /etc/passwd

Шаг 5. Финальная установка пароля

Теперь препятствий нет. Задайте нормальный пароль прямо сейчас, чтобы войти в графический интерфейс без проблем.

passwd имя_пользователя

(Например: passwd cdr)

Введите новый пароль дважды. Вы должны увидеть заветное сообщение:

passwd: all authentication tokens updated successfully

Шаг 6. Перезагрузка

Теперь можно перезагружаться. Введите:

reboot -f

После загрузки вы сможете войти в систему. Ошибка «Извините, в данный момент это не работает» исчезнет, так как мы восстановили права доступа и корректно обновили токен.


P.S. Существуют и другие методы сброса, например, через Live CD или специализированные утилиты вроде Rescatux или SystemRescue. Они позволяют сбросить пароль в пару кликов, но если под рукой нет флешки с инструментами, а доступ к системе нужен "здесь и сейчас" - метод выше работает безотказно.