# Kindle Voyage 5.13.6 Dashboard/SSH 一次成操作手册

本文基于 2026-03-15 的一次实机排障整理，目标是让下次同型号 Kindle 在安装 dashboard、开启调试、打通 SSH 时尽量一次完成，不再重复今天这 5 个小时的试错过程。

## 适用范围

- Kindle Voyage
- 固件 5.13.6
- 已完成越狱
- 已安装 KUAL
- 通过 MRPI 安装扩展
- 目标项目为本仓库 `dash/`

## 最终结论

今天最终打通的稳定路径不是 USB 直连 SSH，而是：

1. Kindle 本机先通过 KTerm 拉起 `dropbear`
2. 让 `dropbear` 监听 `*:22`
3. 从 Mac 通过 Kindle 的 Wi-Fi 地址登录
4. 使用 `~/.ssh/id_ed25519_git` 这把 key

最终验证通过的登录方式：

```sh
ssh -i ~/.ssh/id_ed25519_git root@192.168.72.3
```

后续为了简化操作，已在本机 [~/.ssh/config](/Users/gavin/.ssh/config) 中加入：

```sshconfig
Host kindle
    HostName 192.168.72.3
    User root
    IdentityFile ~/.ssh/id_ed25519_git
    IdentitiesOnly yes
    PreferredAuthentications publickey
    PasswordAuthentication no
    KbdInteractiveAuthentication no
```

所以当前可直接：

```sh
ssh kindle
```

## 下次同型号设备的推荐顺序

### 1. 路由器和网络先处理

先确认这几项：

- Kindle 和 Mac 在同一个主 Wi-Fi
- 不是 Guest Wi-Fi
- ASUS Lyra Trio 中 `禁止无线用户互通` 为关闭

这一步的意义是先保证 Mac 能访问 Kindle 的 Wi-Fi 地址。今天前期大量时间都浪费在这里。

注意：

- Kindle 有时不回 `ping`
- 但这不等于 SSH 不通
- 真正应检查的是 `arp`、`nc -vz <ip> 22`、`ssh`

### 2. Kindle 端必装内容

建议固定安装：

- KUAL
- USBNetwork
- KTerm
- 本仓库 dashboard 文件

其中：

- USBNetwork 用于提供 `usbnet` 和调试工具
- KTerm 是本地 root shell，是真正的兜底入口

今天的结论是：  
一旦外部 SSH 不通，不要继续盲猜，直接进 KTerm 才是最快路线。

### 3. Dashboard 调试先关闭自动挂起

调试 dashboard 时，先在 KUAL 中执行：

1. `Dashboard Debug On`

调试结束后再执行：

1. `Dashboard Debug Off`

相关脚本：

- [dash/src/debug-on.sh](/Users/gavin/kindle-dash/dash/src/debug-on.sh)
- [dash/src/debug-off.sh](/Users/gavin/kindle-dash/dash/src/debug-off.sh)
- [dash/src/start-debug.sh](/Users/gavin/kindle-dash/dash/src/start-debug.sh)
- [dash/KUAL/kindle-dash/menu.json](/Users/gavin/kindle-dash/dash/KUAL/kindle-dash/menu.json)

核心经验：

- 调试时不要让设备自动 suspend
- 否则 KUAL 很容易刚打开就被挂起打断

## 今天确认过的关键事实

### 1. KUAL 的 `sshd up/down` 不是最终真相

今天多次出现：

- KUAL 显示 `sshd up`
- 但设备本机并没有 `sshd` 或 `dropbear` 进程

所以后续一律以本机 shell 为准：

```sh
/mnt/us/usbnet/bin/lsof -n -P -iTCP:22
ps -ef | grep -E 'sshd|dropbear'
```

### 2. `169.254.148.176` 不是 Kindle 的 USBNetwork 地址

这是今天最关键的坑之一。

我们最后确认：

- `169.254.148.176` 是 Mac 自己 USB 网卡的链路本地地址
- Kindle 在 `usbnet` 模式下的真实 USB IP 是 `192.168.15.244`

这个值来自当天在 Kindle 本机采集到的 `collect.log`：

```text
usb0 inet addr:192.168.15.244
```

以及 `usbnet` 配置：

```sh
KINDLE_IP=192.168.15.244
```

也就是说：

- 之前对 `169.254.148.176` 的 SSH 测试，实际上是在连 Mac 自己那块接口
- 这就是为什么前面很多现象互相矛盾

### 3. USBNetwork 直连链路没有最终打通

即使：

- Mac 端给 `en8`/`en11` 配了 `192.168.15.201/24`
- Kindle 端 `dropbear` 看起来监听了 `*:22`

最终 ARP 仍然不通，表现为：

- `arp` 中 `192.168.15.244` 为 `incomplete`
- `nc -vz 192.168.15.244 22` 超时

所以这次真正可用的 SSH 入口，不是 USB 直连，而是 Wi-Fi。

### 4. 真正成功的是 Wi-Fi 上的 DropBear

最终确认：

- Wi-Fi IP 是 `192.168.72.3`
- 服务端 banner 是 `dropbear_2020.81`
- 成功接受的密钥是 `~/.ssh/id_ed25519_git`

验证结果：

- `nc -vz 192.168.72.3 22` 成功
- `ssh -i ~/.ssh/id_ed25519_git root@192.168.72.3 true` 成功
- 可拿到 `uid=0(root)`

### 5. 设备实际跑的是手工拉起的 DropBear

最终有效进程不是系统默认那份 OpenSSH，而是我们在 Kindle 本机手工拉起的：

```sh
bin/dropbearmulti dropbear -F -E -p 22 -P /mnt/us/usbnet/run/dropbear-force-22.pid -n
```

其中：

- `-p 22` 监听 22 端口
- `-n` 是这个 Kindle hack 里的“禁用密码检查”开关

`dropbear -h` 已实机确认：

```text
-n Disable password checking (/!\ Kindle hack, don't use this!)
```

## 一次成的推荐操作

### A. 第一次准备

1. 越狱
2. 安装 KUAL
3. 安装 USBNetwork
4. 安装 KTerm
5. 同步 dashboard 到 `/mnt/us/dashboard`
6. 同步 KUAL 菜单到 `/mnt/us/extensions/kindle-dash`

### B. Dashboard 调试

1. KUAL -> `Dashboard Debug On`
2. 调试完成后再 `Dashboard Debug Off`

### C. SSH 启动的最短稳定路线

如果外部 SSH 一开始就不通，不要继续折腾 USB。

先把仓库里的 Kindle 辅助脚本复制到设备根目录：

```sh
scp /Users/gavin/kindle-dash/scripts/kindle/*.sh kindle:/mnt/us/
```

如果这时还没有 `ssh kindle`，也可以先通过 USB 存储模式手动拷到 `/mnt/us/`。

然后在 Kindle 本机的 KTerm 里执行：

```sh
sh /mnt/us/ssh-force-dropbear-22.sh
/mnt/us/usbnet/bin/lsof -n -P -iTCP:22
```

必须看到类似：

```text
dropbear... TCP *:22 (LISTEN)
```

然后从 Mac 走 Wi-Fi 登录：

```sh
ssh -i ~/.ssh/id_ed25519_git root@192.168.72.3
```

或：

```sh
ssh kindle
```

### D. 登录成功后验证

登录后执行：

```sh
id
uname -a
ps -ef | grep -E 'sshd|dropbear|telnetd' | grep -v grep
```

应至少看到：

- `uid=0(root)`
- `dropbearmulti dropbear ... -p 22 ...`

## 今天踩过的坑

### 1. 不要一开始就把重点放在 USB 直连 SSH

USBNetwork 的确安装了，但：

- USBMS 和 USBNetwork 是互斥的
- USB 侧 IP 容易看错
- Mac 侧可能出现多个候选接口
- 接口名、ARP、链路状态都容易误判

所以：

- USB 更适合拷文件
- 真正稳定的远程入口优先走 Wi-Fi SSH

### 2. 不要相信 `ping` 单独判断

今天实际情况是：

- 某些阶段 `ping` 不通
- 但 `ssh` 可以通

所以后续统一使用：

```sh
nc -vz <ip> 22
ssh <host>
```

### 3. 不要把 “出现 Password:” 等同于“密码一定对”

前期出现过：

```text
ssh root@...
Password:
```

这只能说明对端当时有 SSH 在监听。  
不代表：

- 这就是正确的那份 SSH 服务
- 配置文件就是你刚改的那份
- 默认密码一定可用

### 4. 本机 shell 才是最终裁判

如果出现任何矛盾，比如：

- KUAL 说 `sshd up`
- Mac 连不上
- 改过配置却没生效

立即转入 KTerm，本机检查：

```sh
id
ps -ef
/mnt/us/usbnet/bin/lsof -n -P -iTCP:22
cat /mnt/us/usbnet/etc/config
```

## 今天留下的可复用资产

### 1. Dashboard 调试入口

已在仓库中加入：

- [dash/src/debug-on.sh](/Users/gavin/kindle-dash/dash/src/debug-on.sh)
- [dash/src/debug-off.sh](/Users/gavin/kindle-dash/dash/src/debug-off.sh)
- [dash/src/start-debug.sh](/Users/gavin/kindle-dash/dash/src/start-debug.sh)
- [dash/KUAL/kindle-dash/menu.json](/Users/gavin/kindle-dash/dash/KUAL/kindle-dash/menu.json)

### 2. Mac 侧 USBNetwork 辅助脚本

已在仓库中加入：

- [scripts/connect-kindle-usbnet-mac.sh](/Users/gavin/kindle-dash/scripts/connect-kindle-usbnet-mac.sh)

### 3. Kindle 侧 SSH 救援脚本

已在仓库中加入：

- [scripts/kindle/ssh-collect.sh](/Users/gavin/kindle-dash/scripts/kindle/ssh-collect.sh)
- [scripts/kindle/ssh-fix-all-keys.sh](/Users/gavin/kindle-dash/scripts/kindle/ssh-fix-all-keys.sh)
- [scripts/kindle/ssh-force-openssh-22.sh](/Users/gavin/kindle-dash/scripts/kindle/ssh-force-openssh-22.sh)
- [scripts/kindle/ssh-force-dropbear-22.sh](/Users/gavin/kindle-dash/scripts/kindle/ssh-force-dropbear-22.sh)
- [scripts/kindle/ssh-stop-all.sh](/Users/gavin/kindle-dash/scripts/kindle/ssh-stop-all.sh)

推荐复制方式：

```sh
scp /Users/gavin/kindle-dash/scripts/kindle/*.sh kindle:/mnt/us/
```

作用：

- 自动尝试 `en8`、`en11`
- 给候选接口加 `192.168.15.201/24`
- 探测 `192.168.15.244:22`
- 如果 USB 链路能通，再继续尝试 SSH

这次虽然最终证明 USB 不是稳定入口，但这个脚本保留着仍有价值。

## 建议的下次标准流程

下次同型号设备，推荐严格按下面顺序：

1. 先关掉路由器无线隔离，确保 Kindle 和 Mac 在同一主 Wi-Fi。
2. 先把 dashboard 的 `Debug On/Off` 菜单装好。
3. 先装 KTerm，不要等 SSH 坏了才找本地终端。
4. 初次调试先用 `Dashboard Debug On`，避免设备自动挂起。
5. SSH 优先目标设为 Wi-Fi，不要优先押宝 USB 直连。
6. 外部 SSH 不通时，立即转 KTerm。
7. 在 KTerm 手工拉起 `dropbear` 后，再从 Mac 走 Wi-Fi 登录。
8. 登录成功后再考虑要不要继续优化 USBNetwork 或持久化 SSH 配置。

## 当前最短命令

### Kindle 端

```sh
sh /mnt/us/ssh-force-dropbear-22.sh
```

### Mac 端

```sh
ssh kindle
```

如果 `ssh kindle` 不通，先确认：

- Kindle 还连着 Wi-Fi
- 当前 IP 还是 `192.168.72.3`
- `dropbear` 还在 `*:22` 监听

## 最后一条经验

今天真正节省时间的做法不是“继续猜”，而是尽快把问题缩到：

- 这是网络层问题
- 这是进程问题
- 这是 key 问题
- 还是这是错误 IP 问题

一旦拿到本机 KTerm root shell，排障效率会比外部盲试高一个数量级。