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

2026-09-14 22:31:49 +06:00
parent 8ea818b1f9
commit 9f84d8cdbd
4 changed files with 3799 additions and 3 deletions
@@ -19,6 +19,25 @@
 >
 > 📝 Наблюдение 2026-07-31: `ssh truenas_admin@192.168.2.197` **сработал с Mac Кита (Кит)** в ходе диагностики SATA-карты (по явной просьбе Alex). Т.е. локальный IP может работать, но это не гарантировано — при неудаче откатываться на `mallexxx.duckdns.org`.

+> 🔑 **У `truenas_admin` НЕТ приватных ключей** (`~/.ssh` = только `authorized_keys` + `known_hosts`) — это **норма**, не поломка. Следствия:
+> - `truenas_admin` **не может** зайти по SSH на t610 (`Permission denied (publickey)`) — ключа нет. Вход NAS→t610 настроен **от юзера `nas`**, служебным ключом бэкапа (`/mnt/RED_2TB/backup/t610/.ssh/id_ed25519`). См. [[family/plans/t610-backup-to-truenas]] питфолл №1.
+> - `sudo -u nas …` от `truenas_admin` **требует пароля** (`a password is required`) — проверить pull-ключ можно только под root-shell (у Alex он есть).
+> - 🔴 **Не делать вывод «ключа/доступа нет» по `ls ~/.ssh` одного пользователя** — смотреть владельца и путь из скрипта-потребителя.
+
+### Как проверить сетевой путь NAS → t610 (канон, 2026-09-14)
+
+```bash
+# 1) каким src-адресом NAS уйдёт на t610 (важно для from="..." ограничений в authorized_keys)
+ip route get 192.168.2.176        # → dev enp3s0 src 192.168.2.197
+# 2) порт 22 на t610 со стороны NAS (у truenas_admin есть nc)
+nc -w 3 -z 192.168.2.176 22 && echo PORT22_OPEN
+# 3) TCP-forwarding на sshd TrueNAS — ЗАПРЕЩЁН, поэтому `ssh -J truenas …` не работает
+#    (проверять конфиг под своим пользователем: sshd -T | grep allowtcpforwarding)
+```
+
+> ⚠️ **`nc -z` на t610 с NAS = только «порт открыт»**, это НЕ доказательство доступа (аутентификация отдельно).
+> ⚠️ **`macOS → t610` напрямую по `192.168.2.176` — таймаут** (Mac в другой подсети). Единственный путь с Mac на t610 — через локалку/NAT, см. [[family/plans/t610-home-automation]] §2.
+
 ## Железо (проверено 2026-09-10, `lscpu` + `free -h` на живом хосте)

 | Параметр | Значение |
@@ -1,7 +1,7 @@
 ---
 title: t610 → TrueNAS автобэкап конфигов
 created: '2026-09-14'
-updated: '2026-09-14'
+updated: '2026-09-14 (ночь-15: снят ошибочный вывод про from=/no-pty; доступ NAS→t610 работает от юзера nas; добавлены проверка №0 и состав authorized_keys)'
 type: tech
 namespace: family
 status: works-v4
@@ -25,6 +25,15 @@ related:

 > **Задача (п.8 / A3 плана [[family/plans/t610-home-automation]]):** конфиги t610 (HA OS) регулярно складывать на TrueNAS, откуда они автоматически уезжают в Mail.ru Cloud через уже существующий rclone-бэкап TrueNAS.

+> 🔁 **ПРОВЕРКА №0 ПЕРЕД ЛЮБЫМ РАЗБОРОМ «бэкап сломался» (урок 2026-09-14, ночь-15).** Артефакты (свежие `t610-full-*.tar.gz`, пустой `.err`) — это **доказательство, что бэкап работает**. Если файлы свежие и `.err` пуст, **не искать поломку** — сначала проверить, от **какого пользователя** делается прогон:
+> ```bash
+> # бэкап ходит ОТ ЮЗЕРА nas ключом из датасета; от truenas_admin он НЕ работает и не должен
+> ls -la /mnt/RED_2TB/backup/t610/                        # свежие архивы + .err = 0 байт
+> ls -la /mnt/RED_2TB/backup/t610/.ssh/                   # id_ed25519 + config, владелец nas
+> grep -n 'SSHCFG\|SSHHOST\|^#' /mnt/RED_2TB/backup/t610/backup-t610.sh | head
+> ```
+> ⚠️ Ключ бэкапа **не в `~/.ssh`** — он **внутри датасета** `/mnt/RED_2TB/backup/t610/.ssh/`, владелец `nas`. `~/.ssh` у `truenas_admin` пуст — это норма (см. питфолл №1 и [[family/how-to/truenas-access]]).
+
 ## Схема (принята 2026-09-14)

 ```
@@ -103,9 +112,35 @@ 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]].
+> ⛔ **ОШИБОЧНЫЙ ВЫВОД — СНЯТ (проверено 2026-09-14, ночь-15).** Ранее здесь было записано: «тот же `from="192.168.2.197"` отбивает и саму TrueNAS; NAS стучится не как `.197`, поэтому NAS→t610 даёт `Permission denied`». **Это НЕВЕРНО, оба утверждения опровергнуты фактами:**
+> - `ip route get 192.168.2.176` **на TrueNAS** → `dev enp3s0 **src 192.168.2.197**`. Адрес **совпадает** с `from=`, ограничение не срабатывает. (Версия «приходит не с `.197`» — снята.)
+> - Версия «блокирует `no-pty`» — **тоже снята**: прогон с `-T` (PTY не запрашивается) дал тот же `Permission denied (publickey)`.
+> - 🔴 **НАСТОЯЩАЯ ПРИЧИНА:** проверка велась **от `truenas_admin`**, у которого **нет приватного ключа**. Бэкап ходит **от юзера `nas`** ключом `SHA256:PKDB/sTjM8WFitIjSG+vT27x1TOY3F2Vi6y8YFwK5wo`, чей pub прописан в `authorized_keys` на t610. **Доступ NAS→t610 РАБОТАЕТ штатно — как и задумано.**
+>
+> ✅ **`t610-backup-pull` и бэкап — ИСПРАВНЫ, ничего не сломано.** Прогон 2026-09-14 07:34/07:35, `.err` = 0 байт, `nas:nas`.
+> 📌 **ПРАВИЛО ПРОВЕРКИ (запомнить):** проверять pull-ключ **только от юзера `nas` и с его `config`**, а не «от админа вообще»:
+> ```bash
+> # с TrueNAS, от nas (truenas_admin не имеет ключа и не может sudo -u nas без пароля)
+> sudo -u nas ssh -F /mnt/RED_2TB/backup/t610/.ssh/config -o BatchMode=yes t610-backup 'echo ok'
+> ```
+> ⚠️ `sudo -u nas` от `truenas_admin` **требует пароля** (`a password is required`) — это ограничение, **не поломка**. Не делать из этого вывод «ключа нет».
+> ⚠️ **ПИТФОЛЛ МЕТОДА (моя ошибка этой сессии):** `ls ~/.ssh` **от `truenas_admin`** не содержит `id_ed25519` — и на этом основании было ошибочно заявлено «приватных ключей на NAS нет, бэкап сломан». Ключ лежит **внутри датасета**, в `/mnt/RED_2TB/backup/t610/.ssh/`, у юзера `nas`. **Не судить о наличии ключа по `~/.ssh` одного пользователя — смотреть владельца и путь из скрипта (`SSHCFG=$DEST/.ssh/config`).**
 > 📌 **Правка `authorized_keys` на t610 возможна только ИЗНУТРИ t610** (шелл аддона `core_ssh`) — с NAS не сделать: курица и яйцо. Практически — с Mac по локалке `ssh -i ~/.ssh/id_rsa root@192.168.2.176`.

+### 1a. 📋 `authorized_keys` на t610 — фактический состав на 2026-09-14 (две строки)
+
+`/root/.ssh/authorized_keys` и `/data/.ssh/authorized_keys` — **один и тот же файл** (симлинк в аддоне `core_ssh`; править/бэкапить достаточно один).
+
+| # | Ключ | Комментарий | Ограничения | Назначение |
+|---|---|---|---|---|
+| 1 | `ssh-rsa` 2048, `SHA256:UZ8oPNIe8z2bvBOhWQRyt+JWi99oqQnP8N5XAAm5Uhs` | `mallexxx@Alexeys-MBP` | нет | **Alex, интерактивный вход** (с локалки) |
+| 2 | `ssh-ed25519`, `SHA256:PKDB/sTjM8WFitIjSG+vT27x1TOY3F2Vi6y8YFwK5wo` | `t610-backup-pull` | `from="192.168.2.197"`, `no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding` | **служебный pull-ключ бэкапа** (NAS, юзер `nas`) — только стянуть архив |
+
+Проверка состава: `ssh-keygen -lf /root/.ssh/authorized_keys` (даёт оба fingerprint'а с комментариями).
+Бэкапы файла: `authorized_keys.bak-preclean-20260914-211819`, `authorized_keys.bak-20260914-210532`.
+
+> ⚠️ **Питфолл чтения файла с Mac:** разбор строк через `awk '{print $1, $2, $3}'` внутри ssh-команды **ломается** о кавычки ограничений (`from="192.168.2.197"` → `unexpected EOF while looking for matching '"'`). Обход — скрипт-файл на t610 (правило: **не инлайнить сложные команды**, писать скрипт и `scp`).
+

 ### 2. 🔴 `Failed to load datasets: /mnt/.ix-apps/app_configs` — ломает ВЕСЬ UI датасетов
 **Симптом:** UI TrueNAS (Storage → Datasets, Apps, Datasets) — «Failed to load datasets», дерево датасетов не открывается, невозможно создать датасет/шару.
@@ -1,3 +1,10 @@
+---
+updated: >-
+  2026-09-14 (ночь-15: добавлен §2 «Внешний доступ к t610» — SSH снаружи нет,
+  jump через TrueNAS запрещён)
+namespace: family
+status: works
+---
 # t610 — домашняя автоматизация (HA OS)

 > **Единственный рабочий документ по переносу домашней автоматизации с TrueNAS на HP t610.**
@@ -74,9 +81,13 @@
 | **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-кватер-Р** |
+| **С TrueNAS (NAS→t610), `truenas_admin`** | ❌ | `Permission denied (publickey)` — **у `truenas_admin` НЕТ приватного ключа**, и он не может `sudo -u nas` без пароля. Это ограничение учётки, **не поломка доступа** |
+| **С TrueNAS (NAS→t610), юзер `nas` с ключом бэкапа** | ✅ **ДА** | штатный путь автобэкапа: `ssh -F /mnt/RED_2TB/backup/t610/.ssh/config t610-backup`. Ключ `SHA256:PKDB/sTjM8WFitIjSG+vT27x1TOY3F2Vi6y8YFwK5wo` (`t610-backup-pull`, `from="192.168.2.197"`, `no-pty,no-port-forwarding`) — **служебный, только pull архива**. Подробности — [[family/plans/t610-backup-to-truenas]] питфолл №1 |
 | Изнутри самого t610 (шелл аддона `core_ssh`, UI аддона) | ✅ | правит `authorized_keys` |

+> ⛔ **СНЯТО (2026-09-14, ночь-15) — ранее здесь было записано, что NAS→t610 не работает из-за `from="192.168.2.197"` + `no-pty`.** Оба утверждения **опровергнуты**: `ip route get 192.168.2.176` на TrueNAS → `src 192.168.2.197` (**адрес совпадает**), а прогон с `-T` (без PTY) дал тот же отказ. 🔴 **Настоящая причина — проверяли от `truenas_admin`, у которого нет ключа.** Доступ NAS→t610 **работает штатно** от юзера `nas`, как и задумано (бэкап-прогон 14.09 07:34/07:35, `.err` = 0 байт).
+> 📌 **Правило:** наличие ключа проверять **по владельцу и пути из скрипта** (`SSHCFG=$DEST/.ssh/config` → `/mnt/RED_2TB/backup/t610/.ssh/`, юзер `nas`), а **не** по `ls ~/.ssh` одного пользователя. `~/.ssh` от `truenas_admin` пуст и это норма.
+
 > ⚠️ **`/root/.ssh/authorized_keys` и `/data/.ssh/authorized_keys` на t610 — ОДИН И ТОТ ЖЕ файл** (симлинк в аддоне `core_ssh`). Бэкапить/править достаточно один; сверять оба не нужно.
 > ⚠️ **Правка `authorized_keys` возможна ТОЛЬКО изнутри t610** — с NAS её не сделать (курица и яйцо), нужен Mac или руки Alex. См. §5-кватер-Р-3.

@@ -85,6 +96,30 @@

 **Ограничения SSH-аддона:** нет `docker` CLI и нет `python3`. Есть `bash`, `curl`, `jq`, `ha`. **Скрипты для t610 писать на bash + jq.**

+### 🌐 Внешний доступ к t610 (зафиксировано 2026-09-14, факт-проверка)
+
+**Коротко: извне сети — только веб через Caddy. SSH снаружи — НЕТ. Jump через TrueNAS — НЕ РАБОТАЕТ.**
+
+| Путь | Состояние | Доказательство |
+|---|---|---|
+| Веб HA снаружи | ✅ работает | `https://mallexxx.duckdns.org` → **HTTP 200** (Caddy на TrueNAS → `192.168.2.176:80`) |
+| SSH на t610 снаружи | ❌ отсутствует | В redirect'ах роутера `192.168.2.2` **нет** проброса 22 на `.176`. Осталось: `MQTT(1883→.176)`, `TrueNas-SSH(22)`, `caddy_http(80→8088)`, `caddy_https(443→8443)`, `transmission`, `syncthing`, `xray`. `HomeAssistant(8123)` удалён 2026-09-14 (§5-кватер-М) |
+| Jump через TrueNAS (`ssh -J`) | ❌ запрещён | `ssh -J truenas_admin@mallexxx.duckdns.org root@192.168.2.176` → **`channel 0: open failed: administratively prohibited: open failed`** — на sshd TrueNAS запрещён TCP-forwarding (`AllowTcpForwarding no`); `sshd -T` от `truenas_admin` не читается (нет прав) |
+| SSH на t610 из локалки | ✅ работает | `ssh -i ~/.ssh/id_rsa root@192.168.2.176` (аддон `core_ssh`, порт 22) |
+| NAS → t610 (бэкап) | ✅ работает | PULL от юзера **`nas`** ключом `/mnt/RED_2TB/backup/t610/.ssh/id_ed25519` (алиас `t610-backup`). См. [[family/plans/t610-backup-to-truenas]] |
+
+**Сеть NAS → t610 есть:** `nc -z 192.168.2.176 22` **с TrueNAS** → `PORT22_OPEN`; NAS имеет `192.168.2.197/24`, `ip route get 192.168.2.176` → `src 192.168.2.197`.
+
+> ⚠️ **ПИТФОЛЛ проверки доступа NAS→t610 (моя ошибка 2026-09-14, ночь-15):** проверять **только от юзера `nas`** и с его `config`:
+> ```bash
+> sudo -u nas ssh -F /mnt/RED_2TB/backup/t610/.ssh/config -o BatchMode=yes t610-backup 'echo ok'
+> ```
+> Прогон **от `truenas_admin`** всегда даёт `Permission denied (publickey)` — у него **нет** приватного ключа (он лежит в `backup/t610/.ssh/`, владелец `nas`). Это **не поломка**. `sudo -u nas` от `truenas_admin` требует пароля (`a password is required`) — тоже ограничение, не поломка.
+> ⚠️ **ПИТФОЛЛ метода:** не судить о наличии ключа по `ls ~/.ssh` одного пользователя. Смотреть **владельца и путь из скрипта** (`SSHCFG=$DEST/.ssh/config`).
+
+> 📌 **Если понадобится SSH на t610 снаружи** — сейчас такого пути нет; варианты (требуют отдельного решения Alex): ① ключ NAS для интерактивного шелла + `ssh -t truenas_admin@mallexxx.duckdns.org ssh root@192.168.2.176` (forwarding не нужен, т.к. PTY работает); ② проброс 22 на роутере; ③ WireGuard/Reverse-Xray (см. [[family/how-to/wireguard-vpn]], [[family/plans/reverse-xray-3xui-kraken]]). **Ничего из этого не сделано.**
+
+
 ### Полезные команды `ha`

 ```bash