我做了好几年的嵌入式 Linux 项目最早被 Dropbear 圈粉是因为一块 flash 只有 16MB、内存 64MB 的板子死活装不下 OpenSSH 那一整套依赖。后来在 busybox 根文件系统里把 Dropbear 集成进去整个 SSH 服务跑起来只占几 MB 空间瞬间就明白为什么路由器、工业网关、物联网设备到处都在用这个轻量级 SSH 组件。如果你也在做嵌入式 Linux 应用开发或者正被怎么让板子能远程管理这个问题卡住这篇内容应该能帮上大忙。这篇文章适合三类人一是在做嵌入式 Linux 项目想给系统加 SSH 远程管理能力的人二是用 busybox 集成 dropbear却发现网上资料东一块西一块、踩坑全靠猜的人三是想搞清楚 SSH 密钥、免密登录、权限控制这些基础原理但不想看厚重协议文档的人。我会从协议原理讲到交叉编译、再到实际远程登录的完整套路最后把我在真实项目中踩过的坑和排查方法一并交代。1. 为什么嵌入式 Linux 偏爱 DropbearSSH 协议基础与选型对比1.1 SSH 到底是什么它解决了什么问题先抛开 Dropbear 不谈SSHSecure Shell的本质是在不安全的网络上提供一条加密的远程命令通道。你在电脑上敲一条ssh root192.168.1.10其实是在做三件事身份认证、会话加密、远程命令执行。没有 SSH 之前管理员远程登录设备用的是 Telnet用户名密码和所有指令都是明文传输抓包工具一抓一个准在实验室里演示一遍就能把人吓出一身冷汗。SSH 之所以能成为 Linux 远程管理的默认方案关键在于它解决了两个核心问题。第一个问题是如何证明你是你。SSH 提供了密码认证和公钥认证两种方式。密码认证简单但容易受到暴力破解公钥认证则依赖非对称加密体系客户端持有私钥服务器持有公钥登录时通过签名验证身份。第二个问题是如何保证传输过程不被窃听和篡改。SSH 在握手阶段通过 Diffie-Hellman 密钥交换算法协商出会话密钥后续所有数据都走对称加密通道这样即使有人抓到了网络包看到的也是密文。嵌入式设备选 SSH 服务端时标准答案并不是只有 OpenSSH。OpenSSH 功能全面、生态成熟但它的体积和依赖对资源受限的设备并不友好。Dropbear 的出现就是冲着这个痛点去的它实现的协议兼容 SSH-2核心目标是用最小的资源占用干完 SSH 该干的事。1.2 Dropbear 和 OpenSSH 的体量与性能对比我在实际项目里测过一组数据拿同一块 ARM Cortex-A7 的开发板分别编译 OpenSSH 和 Dropbear对比结果很直观对比项OpenSSHDropbear编译后二进制体积约 2MB 以上含依赖约 300-500KB运行期内存占用每个会话约 5-10MB每个会话约 1-2MB依赖库依赖 OpenSSL、zlib 等可选依赖 libtomcrypt/libtommath可静态编译启动时间偏慢极快毫秒级拉起功能覆盖完整协议、SFTP 子服务等核心 SSH 功能、内置 SCP 支持这里要强调一个容易踩坑的点Dropbear 不是阉割版的 SSH它在协议层面是完整的 SSH-2 实现支持公钥认证、端口转发、Agent 转发这些核心能力。它砍掉的主要是 OpenSSH 里面那些嵌入式场景根本用不到的扩展功能以及一些可选的加密算法。对嵌入式设备来说这就叫刚好够用。1.3 什么场景下选 Dropbear什么场景别选不是说 OpenSSH 不好而是要看场景。我做网关类产品和工业控制板时几乎无一例外用 Dropbear原因很实际这类设备 flash 空间紧张而且不需要跑 SFTP 这种重型文件传输协议只需要能远程登录、拷个小文件、跑几条命令。Dropbear 自带的dbclient和scp兼容命令已经覆盖了 90% 的运维需求。但反过来如果你在做一个 x86 架构的通用服务器或者需要 SFTP、端口转发的复杂策略管理那直接上 OpenSSH 更省心。Dropbear 也支持端口转发但配置灵活性和生态工具链确实不如 OpenSSH。选型的时候就记住一句话空间和内存是第一约束条件就选 Dropbear否则没必要折腾。后面我会展开讲编译和集成的细节你会发现它的轻量是设计出来的不是靠偷工减料。2. Dropbear 的交叉编译与系统集成2.1 交叉编译前的准备工具链和目标平台分析嵌入式 Linux 开发环境里交叉编译是最常见的操作。你要在 x86 的电脑上编译出能在 ARM 板子上运行的二进制靠的是交叉编译器。不同厂家给的交叉编译工具链不一样常见的有 arm-linux-gnueabihf-gcc、aarch64-linux-gnu-gcc还有 Buildroot、Yocto 这类构建系统自带的工具链。第一步是确认你手上的工具链版本然后配置环境变量。我这里用一个典型的 ARM 工具链做示范export PATH/opt/arm-linux-gnueabihf/bin:$PATH export CROSS_COMPILEarm-linux-gnueabihf- export CC${CROSS_COMPILE}gccDropbear 的源码可以从它的官网或者开源镜像站拿到解压后目录结构很清晰核心是一个 configure 脚本加一堆 .c 源文件。它不是用 CMake而是传统的 autotools 体系所以编译步骤就是标准的./configure make套路。但嵌入式交叉编译必须在 configure 时指定--host参数让构建系统知道目标平台不是你当前运行的系统。2.2 编译参数和静态编译的选择Dropbear 的 configure 脚本支持大量可选参数我最常用的几个组合是这样./configure --hostarm-linux-gnueabihf \ --disable-zlib \ --disable-pam \ --disable-lastlog \ --disable-utmp \ --disable-wtmp \ --disable-loginfunc这几个参数解释一下--disable-zlib表示不依赖 zlib 压缩库因为很多嵌入式根文件系统里根本没装 zlibDropbear 有内置的替代方案--disable-pam关闭 PAM 认证模块嵌入式系统一般也不需要--disable-lastlog、--disable-utmp、--disable-wtmp都是关掉登录记录相关功能这些功能依赖 /var/log 和 utmp 文件资源受限设备往往没有这些基础设施。静态编译还是动态编译这是我每次都必须强调的问题。默认配置编出来的是动态链接依赖 libc 和 libtomcrypt 这些动态库。如果根文件系统里没有这些库把二进制拷贝过去一运行就是No such file or directory。我比较推荐在嵌入式场景直接用静态编译./configure --hostarm-linux-gnueabihf \ --enable-static \ --disable-zlib \ --disable-pam make PROGRAMSdropbear dropbearkey dbclient scp静态编译后一个 dropbear 二进制就能独立运行完全不依赖目标系统里乱七八糟的动态库部署时拷贝过去就能用。代价是体积会大一倍左右但也就从 300KB 涨到 700KB 而已还是可以接受的。2.3 与 busybox 集成生成 dropbear 密钥文件交叉编译完成后你能得到几个关键二进制dropbear服务端、dropbearkey密钥生成工具、dbclient客户端、scp文件传输。在 rootfs 里集成 Dropbear通常不是把它塞进 busybox 的二进制里而是作为独立的服务由 init 脚本或 busybox 的 init 机制在系统启动时拉起来。第一步是生成主机密钥。SSH 协议要求服务器必须有自己的身份密钥用于握手时向客户端证明我是这个服务器。Dropbear 支持 RSA、ECDSA、ED25519 三种算法。现在技术圈已经不推荐再用 RSA 1024 这种短密钥除非要兼容非常老的 SSH 客户端否则优先选 ED25519 或 ECDSA。生成命令dropbearkey -t ed25519 -f /etc/dropbear/dropbear_ed25519_host_key dropbearkey -t rsa -s 2048 -f /etc/dropbear/dropbear_rsa_host_key我一般会同时生成 ed25519 和 rsa 两把主机密钥原因很现实新客户端优先走 ed25519老客户端只认 rsa两边都备上兼容性最稳。生成完密钥后要注意权限这个文件必须只有 root 能读否则会有安全提示。标准的做法是把 dropbear 的配置文件目录放在/etc/dropbear/权限设为 700。然后是启动脚本。我用 busybox 作为 init 系统时会在/etc/init.d/S50dropbear写一个 shell 脚本#!/bin/sh case $1 in start) echo Starting Dropbear SSH server... /usr/sbin/dropbear -R -p 22 ;; stop) killall dropbear ;; esac-R参数的意思是如果主机密钥文件不存在就自动生成一个临时密钥。这个参数在第一次启动时特别有用能避免因为忘了生成密钥导致服务起不来。但正式产品上我建议还是提前生成固定密钥这样设备重启后主机指纹不会变不然客户端每次连接都提示指纹不匹配运维会很痛苦。2.4 生成 rootfs 镜像时的关键注意点如果你们项目用的是 Buildroot 或 Yocto那就更省心了。Buildroot 里有BR2_PACKAGE_DROPBEAR选项勾上之后它会自动帮你交叉编译、安装到目标目录还会自动生成密钥。Yocto 的话就是IMAGE_INSTALL:append dropbear同样很简单。不过这里有个隐藏坑Buildroot 默认生成的主机密钥是首次启动时生成的如果多个设备刷同一个镜像它们的密钥也完全一样。这在安全要求高的场景是不能接受的。解决方法是让每个设备在首次启动时检测密钥文件是否存在不存在就调用 dropbearkey 重新生成或者直接在量产阶段给每个设备烧写不同的密钥。我第一次做量产时没注意这个问题几十台设备的主机密钥全一样后来被安全审计揪出来尴尬得很。还有一个小细节Dropbear 在运行时需要/var/run或者/dev/pts存在否则伪终端PTY分配会失败远程登录后 shell 起不来。busybox 的默认 rootfs 一般会自动创建这些目录但如果你手工裁剪 rootfs一定要检查这两个路径。3. Dropbear 远程登录实战从密码连接到免密密钥配置3.1 首次登录密码认证和权限控制设备上电Dropbear 服务起来后在你的 Linux 电脑上直接跑ssh root192.168.1.100这里有个嵌入式 Linux 项目的经典问题root 用户能不能直接 SSH 登录很多刚接触嵌入式 Linux 的朋友发现自己怎么配都登录不了其实是因为 SSH 服务端默认禁止 root 远程登录。Dropbear 和 OpenSSH 在这点上设计类似但 Dropbear 更简单它默认是允许 root 登录的只要密码正确。如果你的系统里还有普通用户并且希望运行的用户列表更可控可以在启动 dropbear 时加-g参数开启密码登录或者用-A参数限定只有特定用户能登录。我在项目里的习惯是开发和调试阶段直接用 root 登录图省事但产品销售阶段一定开普通用户并把PermitRootLogin相关的策略收紧。针对热词里提到的设置只有 wheel 组的用户可以 ssh 远程登录和如何取消 root 登录这类问题我想多说两句。Dropbear 本身不支持 PAM所以它没有AllowGroups这种细粒度配置项。如果你要在 Dropbear 下实现只有某个组的用户能 SSH 登录通常的做法是在登录脚本或者包装脚本里做判断比如在/etc/passwd里把需要禁止登录的用户的 shell 改成/bin/false或者启动 dropbear 时用-A指定允许的用户列表例如/usr/sbin/dropbear -A admin这样只有 admin 用户能通过 SSH 登录其他用户一律拒绝。虽然不如 OpenSSH 的配置灵活但在嵌入式场景下够用了。3.2 SSH 密钥认证的原理和配置步骤人机交互式的密码登录在开发调试时还行但如果你管理几十台设备每天一台台输密码不现实。而且密码认证默认也是暴力破解的重点攻击面。成熟的方案是配置SSH 公钥免密登录。公钥认证的原理我之前在 1.1 里提过客户端生成一对密钥私钥公钥把公钥放到设备的~/.ssh/authorized_keys文件里之后客户端登录时服务端用这个公钥来验证客户端的私钥签名。听起来简单实际操作有几个关键细节。先在电脑端生成密钥对我推荐用 ed25519ssh-keygen -t ed25519 -C your_email_or_comment -f ~/.ssh/id_ed25519这会生成两个文件id_ed25519私钥自己留好和id_ed25519.pub公钥放到设备上。然后把公钥内容追加到设备的~/.ssh/authorized_keyscat id_ed25519.pub ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys权限这步千万别省。SSH 对 authorized_keys 文件权限非常敏感如果权限是 777 或者属于别的用户服务端会直接忽略这个文件然后要求你用密码登录。我见过很多新手卡在这里日志里报Authentication refused排查半天结果就是 chmod 忘了。设置完之后电脑端再执行ssh root192.168.1.100如果能直接进去说明免密配好了。如果不行可以在电脑端用ssh -v看详细调试输出它会明确告诉你密钥被拒绝了还是权限问题。3.3 VSCode 远程开发让嵌入式板子变成你的云开发机现在很多嵌入式工程师已经不用裸终端了而是用 VSCode 的 Remote-SSH 插件做远程开发。配置思路其实和命令行的ssh完全一样区别只是把连接信息写进~/.ssh/config文件。我自己常用的配置模板Host myboard HostName 192.168.1.100 User root Port 22 IdentityFile ~/.ssh/id_ed25519保存好后在 VSCode 里按 F1输入Remote-SSH: Connect to Host选择myboard就能直接连上板子。连上之后VSCode 会在设备上装一个 server 组件之后你就可以在 VSCode 里像本地开发一样编辑代码、跑终端命令。注意这个 server 组件默认会下载到设备家目录的~/.vscode-server下如果设备 flash 很小记得定期清理。还有一个坑是如果设备防火墙没开 22 端口或者 dropbear 被限制只监听某个 IPVSCode 就会一直卡在 Setting up SSH Host这时候先回到命令行确认ssh myboard能不能通再排查插件问题。3.4 通过 SCP 传输文件嵌入式开发的日常操作代码写好了怎么传到板子上一块跑我常用 Dropbear 自带的scp。编译的时候我把 scp 也编出来了它兼容 OpenSSH 的 scp 命令用法传单个文件scp ./app root192.168.1.100:/usr/bin/传整个目录用-r。这里说一个很多人不知道的细节Dropbear 的 scp 和 OpenSSH 的 scp 在协议兼容上基本没问题但如果 OpenSSH 服务端升级到新版本有时会在传输开始时加一个 SFTP 协议协商过程Dropbear 的 scp 也能处理。真正容易出问题的是旧版本 Dropbear 不支持某些新标记导致传文件时卡死。遇到这种情况升级 Dropbear 到最新稳定版基本都能解决。如果要对传到设备的文件做校验可以先在电脑端跑md5sum传到设备后再跑md5sum对比。这是我每次发布固件版本时必做的动作能避免一个非常隐蔽的问题网络传输过程中出现文件损坏烧到设备里跑起来行为诡异排查半天找不到原因。4. 安全加固与常见问题排查实录4.1 嵌入式设备 SSH 安全的几个基本动作嵌入式设备暴露在网络上被扫描是常态Dropbear 虽然轻量安全配置也不能省。我总结了一下在实际项目里反复用到的安全手段。第一关闭密码登录只保留密钥登录。启动 dropbear 时不加-g参数或者显式用-s参数禁用密码登录disables password auth。这样即使攻击者知道 root 密码没有私钥也进不来。要注意的是如果你第一次配置密钥登录还没成功就把密码登录给关了那你可能把自己锁在设备外面。我的习惯是先在本地测试好密钥登录确认 OK 后再关密码认证。第二修改默认端口。把-p 22改成-p 2222这种不常用端口可以减少大量自动化扫描工具的打扰。注意 Dropbear 启动参数里端口写法和 OpenSSH 不一样只要-p 2222不需要写Port 2222。客户端连接时也要对应改端口ssh -p 2222 root192.168.1.100。第三用 fail2ban 或者简单的脚本做暴力破解防护。但嵌入式设备资源有限不一定跑得动 fail2ban我实际用得多的是一个轻量思路在设备上写一个 shell 脚本循环读 Dropbear 的日志发现某个 IP 认证失败超过 N 次就用 iptables 把它拉黑一段时间。这个方案只要几十行 shell 就能实现比跑 Python 脚本轻量很多。热词里提到的ssh服务器拒绝了密码和ssh连接windows认证失败很多情况下就是暴力破解误封 IP 导致的排查时先看设备端日志。第四不要让 Dropbear 暴露在公网。如果设备必须提供服务把端口限到特定网段或者在防火墙上只放行特定来源 IP。嵌入式设备安全配置的第一原则是最小暴露面能不开端口就不开端口。4.2 遇到 Connection refused 时的排查思路远程登录连不上最常见的表现是ssh: connect to host 192.168.1.100 port 22: Connection refused。这通常意味着设备上的 dropbear 根本没监听这个端口。排查思路从底往上走先在设备上手动启动 dropbear看有没有报错输出。如果提示bad permission或者某个共享库找不到就是文件权限或动态库问题。用netstat -tlnp或ss -tlnp确认 22 端口有没有 LISTEN。确认防火墙规则。很多嵌入式系统默认带 iptables 规则但规则可能没有放行 22 端口容易被忽略。直接用iptables -L -n看。确认 dropbear 的启动脚本是否真的在开机时执行了。busybox init 的执行顺序是按文件名排序的S50dropbear这个文件若权限没有可执行位或者文件系统只读导致脚本启动失败都会静默失败。我一个朋友遇到过一次非常恶心的情况dropbear 在终端手动启动是正常的但开机后就是连不上。后来发现是根文件系统挂载的是只读分区/etc/dropbear目录写不进去密钥生成失败dropbear 启动后自动退出。最后把/etc/dropbear挂到一个可写的 tmpfs 上问题才解决。这类问题在嵌入式设备上太典型了flash 分区规划没做好很多服务都会栽在里面。4.3 密钥登录失败的常见原因和日志排查如果你确定端口通了、dropbear 起来了但还是登录不了而且没有报错提示那就得看认证层面的日志。Dropbear 默认日志输出到系统 syslog有时候设备上没有 syslog 服务日志直接打到控制台。启动 dropbear 时加-E参数可以把日志输出到 stderr方便调试/usr/sbin/dropbear -E -p 22Debug 模式的终极武器是-v参数打印非常详细的调试信息/usr/sbin/dropbear -v -p 22密钥登录失败最常见的三个原因按照我遇到频率排列一是authorized_keys文件权限不对或者所在家目录权限不对。解决办法前面说过了chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys。二是公钥格式不对。Dropbear 默认支持的 authorized_keys 格式和 OpenSSH 基本一致但如果你用第三方工具生成的公钥或者粘贴的时候把换行符搞坏了服务端解析不到完整公钥认证就会静默失败。检查方法是在设备上手动cat ~/.ssh/authorized_keys看公钥字符串是否完整。三是密钥算法不匹配。客户端默认只发一种认证请求如果客户端生成的密钥类型设备端不支持会直接失败。检查方法是用ssh -v查看客户端实际发送的算法列表再对照 dropbear 编译时支持的算法。4.4 远程批量管理和 Git 密钥配置的实战记录最后说一个我在多台设备并行管理时特别有用的操作。嵌入式调试往往不止一台设备设备多了就涉及批量操作。传统做法是写一个 for 循环对每个 IP 依次执行命令。但每次都要输密码非常烦所以我一般先把所有设备免密打通然后写脚本批量跑。比如批量查看设备当前运行时间for ip in 192.168.1.101 192.168.1.102 192.168.1.103; do echo $ip ssh -o ConnectTimeout5 root$ip uptime done-o ConnectTimeout5的意思是连接超时 5 秒设备没响应就直接跳过去避免脚本卡死在一台离线设备上。我建议所有批量脚本都加这个参数。还有 Git 仓库配合 SSH 密钥的场景热词里有很多关于 gitlab 配置 ssh 密钥和 gerrit 配置 ssh 密钥的搜索。虽然那是服务器上 OpenSSH 的领域但原理完全一样把生成的公钥粘贴到 GitLab/Gerrit 后台本地仓库的 remote 地址改成 git形式提交和拉取就不再需要输密码。如果你在设备上也需要维护 Git 仓库比如做远程升级时的版本管理也可以给设备生成一对独立的密钥把公钥加到 GitLab 里。这样设备也能直接git pull拉取新版本省去每次手动传文件的麻烦。4.5 关于 VSCode 连接 Windows 认证失败和 SSH 配置文件的冷门坑很多初学者在 Windows 上装 VSCode 连远程服务器报ssh: connect to host github.com port 22: Connection refused或者连 Windows 本身报认证失败这里面有几种情况。如果是连 GitHub 时遇到 22 端口拒绝很可能是本地网络对 22 端口做了限制可以试试用 SSH over HTTPS 的 443 端口因为 GitHub 支持ssh.github.com:443把~/.ssh/config里配成Host github.com HostName ssh.github.com Port 443 User git这个经验虽然是针对 GitHub 的但在嵌入式场景也有参考价值客户端到设备之间如果有中间网络做了端口封锁也经常要改端口或者用端口转发绕过。排查问题时先记住一个原则先确认 TCP 层通不通再看 SSH 服务层能不能过不要上来就怀疑密钥配置。VSCode 报could not open your ssh configuration file这种错基本是~/.ssh/config路径或者文件权限有问题。Windows 上尤其容易出现因为家目录可能不是你以为的那个路径。解决办法是在 VSCode 设置里明确指定 SSH 配置文件路径或者打开命令面板手动选择 config 文件。连 Windows 认证失败多半是因为 Windows 的 OpenSSH Server 默认没有开启密码认证或者防火墙没有放行 22 端口。这类问题不属于 Dropbear 范围但排查思路和嵌入式设备一模一样先看服务有没有起来再看防火墙最后看认证配置。5. 写在最后的几个实战心得Dropbear 在我职业生涯里解决过太多又小又要能远程的难题这里最后补几条从实际项目里总结出来的体会。第一能提前生成密钥就提前生成不要依赖-R参数运行时生成。特别是批量出货的设备统一镜像会导致所有设备主机密钥相同这个是安全红线。量产脚本里加一步每台设备生成唯一密钥的流程一劳永逸。第二交叉编译后的 dropbear 一定要在实际板子上跑一轮完整测试再发布固件。我在 x86 虚拟机上测试一切正常交叉编译到 ARM 板子上后SSH 登录可以但 scp 传文件总断。后来发现是编译时开启了一些特定优化选项导致 SSL 层内存对齐问题换掉编译器优化参数后正常。嵌入式环境的工具链差异一定要靠实机验证兜底。第三别小看日志的重要性。嵌入式设备没有显示器远程管理是唯一入口一旦 SSH 挂了设备就成了黑盒只能寄希望于串口。所以我建议在系统设计里留一条串口调试口作为最后保底同时把 dropbear 日志尽量打到一个持久化存储位置比如 /tmp 或可写分区方便出事之后回溯。这个内容后续还可以往两个方向扩展一是做一套完整的运维脚本把设备上线自动生成密钥、自动上报主机指纹、批量执行命令这些流程串起来二是和现有嵌入式 CI/CD 流程结合让设备出厂前就能自动通过 SSH 完成固件自检和配置下发。反正 Dropbear 只是一个入口进去之后能玩出的花样完全取决于你的想象力。