[2026-09-14] eagle: family/how-to/truenas-access.md family/plans/t610-backup-to-truenas.md family/plans/t610-home-automation.md

family/how-to/truenas-access.md

@@ -103,6 +103,36 @@ docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 s
 > ```
 > Существующие redirect-правила OpenWrt → TrueNAS(192.168.2.197): MQTT 1883, SSH 22, caddy_http 80→8088, caddy_https 443→8443, HomeAssistant 8123 (disabled).
 
+## Доступ с TrueNAS на другие хосты
+
+### 🔴 ЗАПРЕТ TCP-forwarding на sshd TrueNAS (проверено 2026-09-14)
+
+```bash
+# с Mac: попытка прыгнуть через NAS на домашний хост
+ssh -J truenas_admin@mallexxx.duckdns.org root@192.168.2.176
+→ channel 0: open failed: administratively prohibited: open failed
+```
+**`AllowTcpForwarding no`** — `-J`/`-L`/`-W` через TrueNAS **не работают**. Обход — только «двойной ssh» без forward:
+```bash
+ssh -t truenas_admin@mallexxx.duckdns.org ssh root@192.168.2.176
+```
+> ⚠️ **ПИТФОЛЛ:** `sshd -T | grep allowtcpforwarding` от `truenas_admin` даёт **пусто** (нет прав читать эффективный конфиг). Это **не** признак «forward разрешён» — судить только по факту: ошибка `administratively prohibited` = закрыт.
+
+### NAS → t610 (HA OS): пока НЕТ доступа — ключ ограничен
+
+| Проверка | Результат |
+|---|---|
+| Сеть / порт | ✅ `nc -w 3 -z 192.168.2.176 22` → **OPEN** (на NAS `nc` — GNU, `-z` работает) |
+| SSH с NAS | ❌ `root@192.168.2.176: Permission denied (publickey)` |
+
+**Причина — не «ключа нет», а ключ непригоден.** На t610 в `authorized_keys` лежит служебный ключ бэкапа `t610-backup-pull` с ограничениями **`from="192.168.2.197"`** + **`no-pty`/`no-port-forwarding`**: NAS стучится изнутри локалки **не как `.197`** → отказ; и даже при совпадении адреса `no-pty` не дал бы интерактивного шелла.
+
+> 📌 **Ключи NAS:** `~truenas_admin/.ssh/` = **только** `authorized_keys` + `known_hosts`, **приватных ключей нет**. Приватный ключ бэкапа лежит в **`/mnt/RED_2TB/backup/t610/.ssh/id_ed25519`** (+ `config` с алиасом `t610-backup`) — не в `~nas/.ssh`.
+> 📌 **`authorized_keys` на t610 правится только ИЗНУТРИ t610** (шелл аддона `core_ssh` / UI аддона Terminal & SSH). С NAS — курица и яйцо; практически делать с Mac по локалке: `ssh -i ~/.ssh/id_rsa root@192.168.2.176`.
+> 📌 На t610 `/root/.ssh/authorized_keys` и `/data/.ssh/authorized_keys` — **один и тот же файл** (симлинк в аддоне).
+
+**Полный разбор, варианты решения (A/B/C) — §5-кватер-Р** доки [[family/plans/t610-home-automation]]. Смежный питфолл `from=.197` — №1 доки [[family/plans/t610-backup-to-truenas]].
+
 ## Пул и датасеты
 
 Пул: RED_2TB (ZFS)

family/plans/t610-backup-to-truenas.md

@@ -103,6 +103,10 @@ ssh -F /mnt/RED_2TB/backup/t610/.ssh/config t610-backup 'echo ok'
 ```
 > ⚠️ Это тот же питфолл `.157` = NAT Rasputin, что уже задокументирован для логов HA.
 
+> 🔴 **Развитие (2026-09-14, ночь-15):** тот же `from="192.168.2.197"` **отбивает и саму TrueNAS** при попытке зайти на t610 — TrueNAS стучится изнутри локалки **не как `.197`**, поэтому NAS→t610 даёт `Permission denied (publickey)`, хотя порт 22 открыт (`nc -z` ✅). Плюс у ключа `no-pty` — интерактивного шелла он не даст **в принципе**. **Итог: `t610-backup-pull` — служебный ключ, для доступа с NAS непригоден; не «чинить» его (ограничение намеренное), нужен отдельный ключ.** Разбор + варианты — **§5-кватер-Р** доки [[family/plans/t610-home-automation]].
+> 📌 **Правка `authorized_keys` на t610 возможна только ИЗНУТРИ t610** (шелл аддона `core_ssh`) — с NAS не сделать: курица и яйцо. Практически — с Mac по локалке `ssh -i ~/.ssh/id_rsa root@192.168.2.176`.
+
+
 ### 2. 🔴 `Failed to load datasets: /mnt/.ix-apps/app_configs` — ломает ВЕСЬ UI датасетов
 **Симптом:** UI TrueNAS (Storage → Datasets, Apps, Datasets) — «Failed to load datasets», дерево датасетов не открывается, невозможно создать датасет/шару.
 **Причина:** после пересоздания пула (2026-08-21) каталог `app_configs` внутри датасета `ix-apps` не был создан. UI на старте **безусловно** читает `/mnt/.ix-apps/app_configs` и валит всё дерево.

family/plans/t610-home-automation.md

@@ -67,6 +67,20 @@
 
 **Про SSH:** в HA OS SSH выключен по умолчанию. Включается аддоном `core_ssh` (Terminal & SSH): положить публичный ключ в `authorized_keys`. Пароля root не существует, вход только по ключу.
 
+**Откуда реально можно зайти на t610 (`192.168.2.176:22`) — проверено фактом 2026-09-14:**
+
+| Источник | Работает? | Примечание |
+|---|---|---|
+| **Mac по локалке** | ✅ **ДА** | `ssh -i ~/.ssh/id_rsa root@192.168.2.176` — **единственный рабочий путь с Mac** |
+| Mac напрямую (внешне) | ❌ таймаут | Mac в другой подсети → ходим только через `mallexxx.duckdns.org`, а он ведёт на **HA (80)**, не на SSH |
+| Mac через `-J truenas…` | ❌ | на sshd TrueNAS **запрещён TCP-forwarding** (`administratively prohibited`) |
+| **С TrueNAS (NAS→t610)** | ❌ пока нет | сеть и порт 22 открыты (`nc -z` ✅), но `Permission denied (publickey)` — **ключ NAS (`t610-backup-pull`) ограничен `from="192.168.2.197"` + `no-pty` и для входа не годится**. Разбор и варианты — **§5-кватер-Р** |
+| Изнутри самого t610 (шелл аддона `core_ssh`, UI аддона) | ✅ | правит `authorized_keys` |
+
+> ⚠️ **`/root/.ssh/authorized_keys` и `/data/.ssh/authorized_keys` на t610 — ОДИН И ТОТ ЖЕ файл** (симлинк в аддоне `core_ssh`). Бэкапить/править достаточно один; сверять оба не нужно.
+> ⚠️ **Правка `authorized_keys` возможна ТОЛЬКО изнутри t610** — с NAS её не сделать (курица и яйцо), нужен Mac или руки Alex. См. §5-кватер-Р-3.
+
+
 **Хостовый SSH (debug 22222) — не нужен.** Включить по сети нельзя: `ha host` не имеет ssh-команд, Supervisor API `/host/services/ssh` → 403 (роль аддона `manager`), только флешка с меткой `CONFIG`. Привязка serial решается штатным `uart: true`, хостовый шелл не требуется.
 
 **Ограничения SSH-аддона:** нет `docker` CLI и нет `python3`. Есть `bash`, `curl`, `jq`, `ha`. **Скрипты для t610 писать на bash + jq.**
@@ -3628,3 +3642,62 @@ Raw RTU: 14 01 01 00 55 84
 **Проверка числа катушек:** в логе slave 20 виден только `Func: 0x1` (READ COILS) и `0x5` (WRITE COIL `addr=1 value=0xFF00` = «включить»). Bridge **не обслуживает** slave 20 (`configured_slave_ids` — только `1,2,3,10,100–104`), т.е. отвечает **не bridge**, а физическое устройство ZONT. Ответы на WRITE в логе — тоже битые/наложенные.
 
 **➡️ Открыто:** чтобы достоверно узнать состояние slave 20 — нужен пассивный сниффер БЕЗ наложения рамок (иначе данные недостоверны). Ранее записанное «slave 20 = Газ котёл вкл (отвечает ✅)» (см. §9 «Замечание к задаче») — **НЕ подтверждено наблюдением, поправлено там же**.
+
+---
+
+## §5-кватер-Р. 🔑 Доступ с TrueNAS на t610 — разбор и ЧТО МЕШАЛО (2026-09-14, ночь-15)
+
+**Триггер:** Alex — *«Ssh доступ к t610 через truenas у нас есть?»* → *«То есть truenas не заходит на t610 потому что ключ не добавлен?!»* → *«Добавь»*.
+
+### Р-1. Результат проверки (факты, до правок)
+
+| Проверка | Команда | Результат |
+|---|---|---|
+| Mac → TrueNAS | `ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org` | ✅ работает |
+| Mac → t610 через jump | `ssh -J truenas_admin@mallexxx.duckdns.org root@192.168.2.176` | ❌ `channel 0: open failed: administratively prohibited: open failed` — **TCP-forwarding на sshd TrueNAS ЗАПРЕЩЁН** (`AllowTcpForwarding no`; `sshd -T` от `truenas_admin` пуст — нет прав на чтение конфига) |
+| Сеть NAS → t610 | с TrueNAS: `nc -w 3 -z 192.168.2.176 22` | ✅ **PORT22_OPEN** — сеть и sshd t610 в порядке |
+| SSH с TrueNAS на t610 | с TrueNAS: `ssh -o BatchMode=yes root@192.168.2.176` | ❌ **`Permission denied (publickey)`** |
+| Mac → t610 напрямую | `ssh root@192.168.2.176` **с Mac** | ❌ таймаут (Mac в другой подсети — штатно, питфолл `.157`) |
+| Mac → t610 по локалке | `ssh -i ~/.ssh/id_rsa root@192.168.2.176` | ✅ **работает** (единственный рабочий путь с Mac) |
+
+### Р-2. 🔴 КОРНЕВАЯ ПРИЧИНА — ключ NAS УЖЕ добавлен, но он непригоден для интерактивного входа
+
+**Ключ TrueNAS на t610 есть.** Это **не** «ключ не добавлен». Содержимое `/root/.ssh/authorized_keys` **и** `/data/.ssh/authorized_keys` на t610 (это **один и тот же файл** — `/root/.ssh` в аддоне `core_ssh` симлинк на `/data/.ssh`; править любой, проверять оба не нужно) — **2 строки**:
+
+| # | Ключ | Ограничения / параметры |
+|---|---|---|
+| 1 | `ssh-rsa … mallexxx@Alexeys-MBP` (2048, Mac) | без ограничений → ✅ **этот даёт вход** (`SHA256:UZ8oPNIe8z2bvBOhWQRyt+JWi99oqQnP8N5XAAm5Uhs`) |
+| 2 | `ssh-ed25519 … t610-backup-pull` | 🔴 **`from="192.168.2.197"`** + **`no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`** (`SHA256:PKDB/sTjM8WFitIjSG+vT27x1TOY3F2Vi6y8YFwK5wo`) |
+
+**Почему строка №2 отбивает NAS — ДВА независимых запрета:**
+1. 🔴 **`from="192.168.2.197"` не совпадает.** TrueNAS стучится на t610 **изнутри локалки с другого адреса**, а не как `.197` → sshd t610 отвергает ключ → `Permission denied (publickey)`. **Это правильное поведение ограничения, а не поломка ключа** (тот же механизм, что в питфолле №1 доки [[family/plans/t610-backup-to-truenas]], только там — Mac как `.157`).
+2. 🔴 **`no-pty`** — даже при совпадении адреса интерактивного шелла **не будет** (нет TTY). Ключ спроектирован строго под **неинтерактивный pull бэкапа**, а `no-port-forwarding` заодно убивает и вариант «через `-L`-туннель».
+
+> 📌 **Вывод для будущих сессий:** `t610-backup-pull` — **служебный ключ бэкапа, для доступа с NAS он непригоден в принципе.** Не пытаться «починить» его: расширение `from`/снятие `no-pty` **сломает изоляцию бэкап-ключа** (решение №5 доки бэкапа — ограничение намеренное). Нужен **отдельный** ключ.
+
+### Р-3. ⚠️ ВАЖНО для плана работ: все попытки правки SSH с NAS будут ПРОВАЛИВАТЬСЯ на доступе к файлу
+
+С TrueNAS **невозможно** отредактировать `authorized_keys` на t610 — и это **не** решается добавлением ключа:
+
+- SSH-доступ с NAS требует ключа **в** `authorized_keys` → **курица и яйцо**;
+- другого пути с NAS нет: `authorized_keys` правится **только изнутри t610** (шелл аддона `core_ssh` или UI аддона Terminal & SSH);
+- **внутрь t610 сейчас попасть можно только с Mac** (см. Р-1) — значит любая такая правка делается **с Mac либо руками Alex**.
+
+**Обход «курицы и яйца» один из двух:**
+1. **С Mac** (текущий рабочий путь): зайти `ssh -i ~/.ssh/id_rsa root@192.168.2.176` → дописать pub-ключ NAS в `/root/.ssh/authorized_keys` (сделав бэкап файла заранее). После этого NAS ходит на t610 как обычный юзер (новый ключ — **без** `from=` и **без** `no-pty`, с `no-port-forwarding`).
+2. **Руками в UI**: Настройки → Аддоны → Terminal & SSH → вкладка Terminal → `nano /root/.ssh/authorized_keys` (писать pub-ключ NAS **одной строкой**).
+
+### Р-4. 📌 Выбор варианта доступа (план, ожидает апрува Alex)
+
+| Вариант | Суть | Плюсы | Минусы / риски |
+|---|---|---|---|
+| **A (рекомендуется)** | Новый ключ `id_ed25519_t610` на NAS → pub в `authorized_keys` t610 (без `from`, без `no-pty`, с `no-port-forwarding`) → вход `ssh -t truenas_admin@mallexxx.duckdns.org ssh root@192.168.2.176` (`-J` НЕ нужен, forwarding запрещён) | простой, обратимый, не трогает бэкап-ключ | нужен Mac **или** Alex для однократной правки файла |
+| **B** | `socat`/постоянный туннель на NAS | «прозрачный» порт | **root-операция**, зависит от sshd-политики, минное поле, лишний демон |
+| **C** | Ничего не делать: t610 администрируется **изнутри** (шелл аддона), с Mac — по локалке | нулевой риск | с NAS на t610 напрямую не зайти |
+
+> ⚠️ **Р-5. Питфолл диагностики:** `sshd -T | grep -i allowtcpforwarding` **от `truenas_admin` не работает** (пустой вывод — нет прав читать эффективный конфиг). О запрете forwarding судить **по факту**: ошибка `administratively prohibited: open failed` при `-J` = forwarding закрыт. Не делать вывод «конфиг пуст → forward разрешён».
+>
+> ⚠️ **Р-6. `nc` на NAS — GNU, `-z` работает** (`nc -w 3 -z <host> <port>`), в отличие от busybox-`nc` на OpenWrt, где `-z` молча врёт (см. §2 «Роутеры»).
+>
+> ⚠️ **Р-7. Ключи на NAS:** `~/.ssh` у `truenas_admin` содержит **только** `authorized_keys` (2060 б) + `known_hosts` — **приватных ключей там НЕТ**. Приватный ключ бэкапа лежит **не** в `~nas/.ssh`, а в `/mnt/RED_2TB/backup/t610/.ssh/` (питфолл №9 доки [[family/plans/t610-backup-to-truenas]]) — при поиске «а есть ли у NAS ключ» смотреть **туда**, а не только в `~/.ssh`.
+