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

调试结束后再执行：

1. Dashboard Debug Off

相关脚本：

• 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. 调试完成后再 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-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，排障效率会比外部盲试高一个数量级。