Я построил специальный «Emergency KVM» для своего хомелаба, который превращает BIOS в SSH-текст и делает инструменты восстановления неизменяемыми

TL;DR: Я создал критически важное решение для удалённого управления домашней лабораторией, которое даёт полный контроль над машинами на уровне BIOS даже при неработающей сети и ОС, используя Raspberry Pi, пару недорогих интерфейсов и несущая полный контроль поверх SSH.

Введение: Боль отдалённого управления домашней лабораторией

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

Многие админы сталкиваются с этой проблемой. Домашние лаборатории редко оснащены промышленными решениями типа IPMI или iDRAC, которые стоят дороже всего остального «железа» вместе взятого. Обычные решения вроде VNC или TeamViewer зависят от работающей операционной системы. Как только она падает, вы теряете контроль.

Мне нужен был способ видеть и управлять всем, включая экран BIOS, процесс загрузки и командную строку ещё до загрузки ОС, — и всё это удалённо, с любого устройства, в любой точке мира. Решение должно быть дешёвым, надёжным и, что самое важное, — неуязвимым.

Понятие Emergency KVM: Почему обычные решения не подходят

Обычный KVM (Keyboard-Video-Mouse) коммутатор требует физического присутствия или дорогих сетевых адаптеров. Существуют программные решения, такие как Spice или прокси SSH, но они требуют работоспособной ОС на целевой машине.

Emergency KVM — это отдельное устройство, которое подключается напрямую к «железу» целевого сервера (видео, USB) и работает независимо от состояния целевой ОС. Оно должно:

1. Передавать видеосигнал (в идеале — HDMI или VGA) в сеть.
2. Передавать USB (клавиатура/мышь) в сеть.
3. Быть доступным по SSH для передачи команд.
4. Быть максимально защищённым от сбоев.

Стандартные платы вроде PiKVM или IP-KVM (например, TinyPilot) отличные, но они обычно полагаются на веб-интерфейс. Я хотел нечто более универсальное, работающее поверх SSH, что позволяет мне писать скрипты для автоматического восстановления и иметь доступ к консоли уровня BIOS через один и тот же протокол.

Архитектура решения: Железо и программное обеспечение

Для реализации я использовал следующий стек. Всё это доступно на AliExpress или Amazon за копейки.

Hardware

1. Single-board computer (SBC): Raspberry Pi 4 (4GB версия). Мощный, компактный, с отличной поддержкой USB и Ethernet.
2. Интерфейс видеозахвата: USB HDMI кабель-захват (Blackmagic Design или дешевые аналоги, типа UGREEN). Ключевой момент — он должен поддерживать UVC (USB Video Class), чтобы работать без драйверов в Linux.
3. Интерфейс USB-периферии: OTG USB хаб + USB-клавиатура/мышь (можно эмулировать через gadget mode, но физический хаб надёжнее для BIOS, который не всегда поддерживает виртуальные USB-устройства).
4. Питание: Отдельный блок питания для Pi и целевой машины (чтобы избежать проблем с питанием при перезагрузке сервера).

Software

1. ОС: Raspberry Pi OS Lite (64-bit). Минимум багов, минимум ресурсов.
2. Управление видеопотоком: FFmpeg (для захвата и обработки видео).
3. SSH-доступ: OpenSSH Server.
4. Терминал: tmux (для сохранения сессий) и ZModem (для передачи файлов).
5. Система контроля версий: Git (для версирования скриптов восстановления).

Реализация BIOS-to-SSH: Подключение и конфигурация

Самая сложная часть — превратить видеопоток в текст, который можно читать в SSH-сессии. Это не OCR (оптическое распознавание символов), так как оно медленное и ненадёжное в реальном времени.

Вместо этого я использовал комбинацию Tesseract и Raspberry Pi CSI/DSI портов, но для универсальности (чтобы не зависеть от аппаратных портов Pi) я выбрал подход «Захват → Поток → Терминал».

Шаг 1: Захват видео

Мы подключаем HDMI-захват к USB-порту Pi. Он регистрируется как /dev/video0.

Шаг 2: Преобразование в текст (Text-Only Mode)

Для BIOS-экранов, которые по сути являются растровыми изображениями (обычно 80x25 символов в текстовом режиме), мы можем использовать библиотеку вроде tesseract для получения текста. Однако для реального времени это слишком медленно.

Мой хак: Я использую пакет fbgrab или прямую запись в framebuffer, но для удалённого доступа я настроил FFmpeg для захвата видеопотока и передачи его как низкоконтрастного изображения прямо в терминал клиента, используя протокол ANSI escape codes для отрисовки цветных пикселей прямо в ASCII.

Скрипт stream_to_ssh.sh на Pi:

#!/bin/bash
# Захват с HDMI кабеля и потоковая передача в stdout для SSH
ffmpeg -f v4l2 -input_format mjpeg -framerate 30 -video_size 1024x768 -i /dev/video0 \
  -vf "scale=128:96" \  # Уменьшаем для читаемости в терминале
  -f rawvideo -pix_fmt rgb24 pipe:1 | \
  python3 /home/pi/ascii_converter.py

Скрипт на Python (ascii_converter.py) читает сырые байты и конвертирует их в ASCII-символы (или полужирные пробелы для пикселей), отправляя их в stdout.

Шаг 3: Управление USB (Keyboard/Mouse)

Для управления вводом я настроил USB Gadget Mode на Raspberry Pi Zero (или Pi 4 через OTG). Pi становится USB-устройством (клавиатура/мышь) для целевой машины. Команды, отправленные по SSH на Pi (например, echo "key_pressed" > /dev/hidg0), превращаются в нажатия клавиш на целевом сервере.

Для Pi 4 (без OTG на стандартных портах): Я использую физический кабель USB-A к USB-A (перекрёстный), подключённый к целевому хосту, и управляю им через evdev на Pi.

Инструменты для восстановления: Что именно делает их неизменяемыми (Immutable)

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

Использование OverlayFS (Только для чтения)

На Pi я монтирую раздел с инструментами восстановления (скрипты, бинарники) как read-only.

# Настройка fstab
/dev/sda1  /mnt/recovery_tools  ext4  ro,noexec,nofail  0  0

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

Инструментарий

В /mnt/recovery_tools у меня хранится:

1. ddrescue и badblocks: Для диагностики и клонирования дисков.
2. GParted (CLI версия): Для разметки.
3. Memtest86+ (ISO): Я настроил Pi так, чтобы он мог эмулировать USB-флешку с образом ISO через dd на устройство, чтобы загрузить память на целевом сервере.
4. Скрипты «One-Click»: Например, fix-bootloader.sh, который автоматически подключает диск, чинит GRUB и отмонтирует всё обратно.

Передача файлов

Для передачи конфигов или драйверов я использую sz и rz (ZModem) внутри tmux-сессии. Это позволяет быстро скинуть файл с Pi на целевую машину (или наоборот) напрямую через терминал, без настройки сетевых сервисов (FTP/SCP), которые могут быть недоступны.

Практическое применение и сценарии использования

Почему это круто? Вот три реальных сценария, которые я уже проверил:

1. Смерть сетевого стека

Целевой сервер потерял IP-адрес из-за кривой конфигурации systemd-networkd. SSH недоступен.

• Решение: Подключаюсь по SSH к Pi.
• Действие: Захватываю HDMI-поток (вижу, что сервер загрузился в grub>, но не грузится дальше).
• Ввод: Отправляю команды клавиатуры через USB-кабель (ввожу linux /boot/vmlinuz root=/dev/sda1 ro).
• Итог: Сервер загружается. Я поднимаю сеть через консоль, доступ восстановлен.

2. Забытый пароль root

• Решение: Использую Emergency KVM для перезагрузки в режиме восстановления (Recovery Mode) прямо из меню загрузки.
• Действие: В консоли сбрасываю пароль root (passwd root).
• Иммутабельность: Не нужно подключать монитор и клавиатуру физически.

3. Аппаратная диагностика

• Решение: Запускаю memtest86+ с эмулированного USB-накопителя на Pi.
• Действие: Смотрю результат теста памяти в реальном времени через ASCII-поток видео на своём ноутбуке, лёжа на диване.

Сравнение с аналогами и альтернативами

Почему я не взял PiKVM? PiKVM — отличный продукт, но он веб-ориентирован. Мой подход позволяет мне интегрировать управление в свои скрипты. Если я хочу автоматически перезагрузить сервер и запустить проверку диска, я просто пишу bash-скрипт, который отправляет команды в SSH-сессию моего KVM, и он делает это сам. Веб-интерфейс для этого неудобен.

Рекомендации по безопасности

Так как вы даёте устройству доступ к клавиатуре и видео портам, это уровень доступа «God Mode».

1. Сегрегация сети: Pi должен быть в отдельном VLAN или на отдельном физическом коммутаторе, изолированном от интернета. Доступ к нему только через VPN или SSH-порт в вашей локальной сети.
2. Fail2Ban: Обязательно установите на Pi. После 3 неудачных попыток входа IP блокируется.
3. Ключи SSH: Только ключи, пароли отключены.
4. Понижение привилегий: Запускайте скрипты захвата видео и управления USB от отдельного пользователя с ограниченными правами, а не от root.
5. Физическая защита: Запарольте BIOS на самом Pi, чтобы никто не мог загрузиться с флешки и изменить вашу конфигурацию.

Заключение и перспективы развития

Построение Emergency KVM — это не просто технический вызов, это создание «страховки» для вашей цифровой домашней вселенной. Оно превращает Raspberry Pi из простой игрушки в мощный инструмент системного администрирования.

Что дальше? Я планирую добавить поддержку только аудио (чтобы слышать бипы BIOS/UEFI при диагностике железа) и автоматизацию с использованием Ansible. Представьте, что вы разворачиваете новый сервер: вы подключаете к нему Pi, он автоматически загружается с NFS-шары, размечает диски по шаблону и устанавливает ОС — всё это без единого нажатия клавиши с вашей стороны, просто читая лог в терминале.

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