OnionUI项目中的Dropbear SSH连接问题分析与解决方案

问题背景

在OnionUI 4.3.0版本中，用户报告了一个关于Dropbear SSH服务无法正常建立连接的问题。当用户尝试通过SSH客户端连接时，服务器会在SSH2_MSG_KEXINIT交换后立即终止连接，而不会继续进行SSH2_MSG_KEX_ECDH_REPLY阶段。这个问题在启用或禁用SSH认证的情况下都会出现。

问题分析

通过详细的日志分析和技术调查，发现问题的根本原因与Dropbear服务的临时主机密钥生成机制有关。具体表现为：

1. 连接终止现象：SSH握手过程在密钥交换初始化阶段后异常终止
2. 日志关键信息：Dropbear日志显示"Couldn't create new file /etc/dropbear/dropbear_rsa_host_key.tmp: No such file or directory"
3. 权限问题：系统无法在默认的/etc/dropbear目录下创建临时密钥文件

技术细节

OnionUI项目对标准Dropbear 2022.83版本进行了多项定制化修改，包括：

• 用户登录统一为root账户
• 修改了shell启动方式以避免加载/etc/profile
• 调整了空白密码验证逻辑
• 更改了工作目录和库路径
• 将SSH密钥存储位置重定向到/mnt/SDCARD/.tmp_update/etc/dropbear/

这些修改是为了适应Miyoo Mini设备的特殊存储架构，因为原始的/etc目录位于只读的spi闪存上。

解决方案

经过项目维护者的确认和测试，正确的解决方法是：

1. 创建必要目录：

   mkdir -p /mnt/SDCARD/.tmp_update/etc/dropbear
   

2. 验证目录结构：确保以下路径存在且可写

   • /mnt/SDCARD/.tmp_update/
   • /mnt/SDCARD/.tmp_update/etc/
   • /mnt/SDCARD/.tmp_update/etc/dropbear/

3. 重启Dropbear服务：使更改生效

最佳实践建议

为了避免类似问题，建议：

1. 在系统初始化时自动创建必要的目录结构
2. 在启动Dropbear服务前检查目录存在性和可写权限
3. 考虑在发布包中包含占位文件(.gitkeep)以确保目录结构完整
4. 对于使用版本控制系统的用户，应注意将关键目录纳入版本管理

总结

这个案例展示了嵌入式系统中权限管理和文件系统布局的重要性。OnionUI项目通过将SSH密钥存储重定向到SD卡可写区域，巧妙地解决了只读文件系统的限制。用户遇到此类问题时，应首先检查相关目录的完整性和权限设置。

对于开发者而言，这也提示我们在设计系统时应充分考虑各种使用场景，包括版本控制、系统升级等可能影响文件系统结构的操作，提前做好防御性编程。