Serge Bobrovsky 

Для плюсистов, кто активно юзает нейронки, самое оно.

Книга 1. Гарри Поттер и Неорганический Интеллект.

Глава 1. Библиотека лжёт.

...

Глава 11. Контракт с реальностью.

1.3. Защитите удалённый компьютер.

...Однако оставляя консольный доступ, вы создаёте обходной путь мимо вашей строгой SSH-политики (ключи + IP). Если этот путь защищён слабо, все ваши усилия по SSH теряет смысл.

Слабый пароль на IPMI / iDRAC, устаревшая прошивка с известными уязвимостями, отсутствие двухфакторной аутентификации, консоль доступна без VPN, логирование не настроено...

Консольный доступ -- это просто страховка на случай катастрофы. Вы случайно заблокировали сами себя через sshd_config (опечатка, не те права :), потеряли приватный ключ, SSH-сервер висит или упал, атака вывела SSH из строя...

Без консоли в таких случаях сервер скорее всего придётся переустанавливать, и в целом всё на милость техподдержки (возможно, только через личное присутствие).

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

Консоль только через VPN / выделенную сеть

Отдельные учётные данные, не совпадающие с SSH

Длинный пароль

Никакого root / admin / password

IPMI/iDRAC не должен смотреть в интернет

Двухфакторная аутентификация (если поддерживается)

Аудит и логирование всех входов в консоль

Мониторинг: оповещение при входе в консоль

1.3. Защитите удалённый компьютер.

Желательно разрешить вход только с определённых устройств (т.е. с конкретных приватных ключей).

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

Ограничение по IP + ключ - рекомендуемо.

Можно также ограничить ключ только выполнением определённой команды.

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

Всегда добавляем конечно логирование и мониторинг (обнаружение чужих ключей).

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

Что делать с украденным устройством? Удалите его открытый ключ из authorized_keys на сервере, а если используете сертификаты, добавьте серийный номер в RevokedKeys.

Резюме: юзаем только нужные устройства + только с разрешённых мест + только с конкретными ключами.

1.2. Защитите удалённый компьютер.

...Да, но если SSH-сервер перестанет отвечать или ключ будет утерян, вам капец :)

Оставьте консольный доступ (например, через IPMI / iDRAC / VPS-консоль) на такой случай.

НО! только если вы можете обеспечить для него уровень безопасности, не уступающий SSH. В идеале - консоль не имеет публичного IP, доступна только через КВН, защищена длинным паролем с 2FA, и каждый вход логируется.

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

При настройке VPS безопасность - первоочередная задача. Поскольку на нём будет сосредоточена вся ваша профессиональная деятельность, вам не следует полагаться только на пароль. В идеале следует полностью отключить аутентификацию по паролю и полагаться только на SSH-ключи.

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

По хорошему, ограничение по ключу лучше расширить и ограничением по IP (если они динамические, хорошо бы добавить КВН:),

ещё сильнее подписывать клиентские ключи своим CA-сертификатом,

ну и ведём логирование и мониторинг чужих ключей.

От драйвера до пикселей на экране.

Kernel layer: от DRM (Direct Rendering Manager) к KMS (Kernel Mode Setting)

DDX layer: xf86-video-* для X11 или mesa + libgl для прямого рендеринга

Display server/protocol layer: X11 (Xorg с DDX-драйверами) vs Wayland (композитор сам себе сервер)

Compositing layer: Picom (X11) или встроенный композитор (Wayland)

Session layer: Display Manager (GDM/SDDM) - WM/DE - приложения

В Ubuntu это всё «настройки дисплея».

В Arch вы выбираете например X11 с i3-gaps + picom или Wayland с sway/Hyprland, причём второй не работает с проприетарными драйверами NVIDIA без танцев с nvidia_drm.modeset=1 ...

Это классический клиент-серверный протокол.

X Server -- это программа, которая имеет монопольный доступ к видеокарте. Приложения говорят ей: "Нарисуй мне окно 500x500", сервер рисует и отправляет события обратно.

Минусы:

Любое приложение может прочитать ввод с клавиатуры любого другого окна.

При падении X Server падают все графические приложения.

Мониторы с разной частотой обновления (60 Гц + 144 Гц) работают плохо (тряска).

HDR и HiDPI -- костыли, работают через раз.

Каждое действие проходит длинный путь (App - X Server - GPU).

Это протокол, а не программа. "Композитор" (например, KWin, Mutter, Sway, Hyprland) сам является сервером. Приложение говорит композитору напрямую: «Дай мне участок памяти (buffer), я сам туда нарисую», композитор просто собирает эти буферы и отправляет на экран.

Почему круто:

Приложение не видит ввод других окон.

Путь короткий (App - Compositor - GPU).

Каждое окно рендерится с собственной частотой.

Нет разрывов по определению (если приложение не просит explicit sync).

Почему это уровень стека, а не просто галочка? В большинстве ОС (Windows, macOS, Ubuntu) выбор протокола скрыт от пользователя. А в Arch вы выбираете это сознательно! :)

Вы не ставите «видеодрайвер» и радуетесь, вы выбираете стек:

sudo pacman -S sway wayland libinput mesa

Firmware layer: UEFI (vs legacy BIOS), поиск bootx64.efi

Bootloader layer: systemd-boot/GRUB/EFISTUB - загрузка vmlinuz-linux и initramfs-linux.img

Initramfs layer: ранний userspace с хуками (udev, keyboard, encrypt) - монтирование настоящего root

Init layer: переход к systemd (PID 1) и default.target

В обычных линуксах вы просто смотрите на логотип. В Arch вы правите mkinitcpio.conf, пересобираете initramfs и настраиваете systemd-boot entry вручную :)
p.s. ну или так )
grub-install --target=x86_64-efi --efi-directory=/boot