kindle-calendar/dash/docs/kindle-voyage-5.13.6-dual-ssh-playbook-zh.md

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

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

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

后续为了简化操作，已在本机 ~/.ssh/config 中加入：

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

所以当前可直接：

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
2. Kindle Dashboard

调试结束后再执行：

1. Dashboard Debug Off
2. Kindle Dashboard

相关脚本：

• dash/src/debug-on.sh
• dash/src/debug-off.sh
• dash/src/start-debug.sh
• dash/KUAL/kindle-dash/menu.json

核心经验：

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

今天确认过的关键事实

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

今天多次出现：

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

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

/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：

usb0 inet addr:192.168.15.244

以及 usbnet 配置：

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 本机手工拉起的：

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 已实机确认：

-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. KUAL -> Kindle Dashboard
3. 调试完成后再 Dashboard Debug Off

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

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

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

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

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

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

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

必须看到类似：

dropbear... TCP *:22 (LISTEN)

然后从 Mac 走 Wi-Fi 登录：

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

或：

ssh kindle

D. 登录成功后验证

登录后执行：

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 可以通

所以后续统一使用：

nc -vz <ip> 22
ssh <host>

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

前期出现过：

ssh root@...
Password:

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

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

4. 本机 shell 才是最终裁判

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

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

立即转入 KTerm，本机检查：

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
• dash/src/debug-off.sh
• dash/src/start-debug.sh
• dash/KUAL/kindle-dash/menu.json

2. Mac 侧 USBNetwork 辅助脚本

已在仓库中加入：

• scripts/connect-kindle-usbnet-mac.sh

3. Kindle 侧 SSH 救援脚本

已在仓库中加入：

• scripts/kindle/ssh-collect.sh
• scripts/kindle/ssh-fix-all-keys.sh
• scripts/kindle/ssh-force-openssh-22.sh
• scripts/kindle/ssh-force-dropbear-22.sh
• scripts/kindle/ssh-stop-all.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 /mnt/us/ssh-force-dropbear-22.sh

Mac 端

ssh kindle

如果 ssh kindle 不通，先确认：

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

最后一条经验

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

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

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