BusyBox集成telnetd实现远程登录：项目应用示例

忙得动不如连得上：用 BusyBox 的 telnetd 实现嵌入式远程登录实战

你有没有过这样的经历？
手里的开发板通电后黑屏无输出，串口线插了半天也只看到一串启动日志戛然而止；现场设备突然宕机，但没人能去拆机接线；新烧录的固件起不来系统，可 JTAG 又不支持动态调试……

这时候，如果设备能“自己说话”，哪怕只是让你敲个命令看看dmesg，问题可能瞬间迎刃而解。

在资源紧张、网络可用的嵌入式环境中，我们不需要花里胡哨的 Web 管理界面或加密 SSH 隧道——我们要的是最快的方式连进去看一眼。而这个“最短路径”往往就是：BusyBox + telnetd。

这不是最优的安全方案，但它是最高效的调试手段。今天我们就来聊聊，怎么让一块跑着 Linux 的小板子，在几秒内变成一个可远程登录的命令行终端。

为什么是 BusyBox？因为它“省到极致”

先说个现实：很多嵌入式系统的 Flash 大小只有 8MB 或 16MB，RAM 甚至不到 64MB。在这种环境下，装一套 GNU Coreutils 加 OpenSSH，光依赖库就能占掉一半空间。

而BusyBox，作为“嵌入式 Linux 的瑞士军刀”，把上百个常用工具（ls,cp,ps,mount,init……）全都塞进了一个二进制文件里，通常编译出来还不到 1MB。

它是怎么做到的？
简单讲，它用了“一程序多用途”的设计：

所有命令都指向同一个可执行文件/bin/busybox
当你输入ls，其实是执行了busybox ls
内部通过判断$0（即调用名）决定运行哪个功能模块

于是，/bin/ls、/bin/cp、/bin/grep全都是软链接到/bin/busybox，节省了大量磁盘和内存开销。

更重要的是，它自带了telnetd这个轻量级 Telnet 服务，无需额外安装任何包，只要配置好网络，就能立刻实现远程访问。

telnetd：明文传输但快如闪电的远程入口

别急着喷“Telnet 不安全”。我们知道它的问题——所有数据包括密码都是明文传输。但在内网调试阶段，尤其是在产品原型期，可用性远胜于安全性。

相比 Dropbear 或 OpenSSH 动辄几十 KB 的加密开销和复杂的密钥管理，telnetd几乎零负担：

占用内存极少
启动速度极快
不依赖 PAM、NSS、SSL 库等复杂组件
默认集成在 BusyBox 中，开关一个选项即可启用

它的核心工作流程也很直接：
1. 监听 TCP 23 端口（可自定义）
2. 客户端连接后，创建伪终端（pty）
3. 派生 shell 进程（通常是/bin/sh）
4. 在客户端和 shell 之间转发字节流

整个过程就像给你的设备接了个“虚拟键盘+显示器”，只不过走的是网线。

📌 提示：生产环境务必禁用！仅限开发调试使用！

关键参数怎么配？这几个选项必须掌握

telnetd虽小，但关键参数不多，记牢这几个就够用了：

参数	作用说明
`-l USER`	自动以指定用户登录，跳过用户名输入（适合单用户系统）
`-p PORT`	修改监听端口（比如`-p 2323`避免被扫描发现）
`-i`	禁止认证，直接启动 shell（极度危险，仅用于救砖）
`-F`	前台运行，方便查看日志输出（调试时强烈推荐）

🌰 常见用法示例：

# 以 root 用户身份启动，前台运行便于观察 telnetd -l root -F & # 使用非标准端口，降低暴露风险 telnetd -l root -p 2323 & # 救急模式：无密码直连（慎用！） telnetd -i -F &

这些命令可以写进启动脚本，系统一联网就自动开启服务。

怎么让它开机自启？三步搞定

要在设备上电后自动提供远程登录能力，我们需要完成三个关键步骤：

第一步：确保根文件系统由 BusyBox 构建

这是前提。检查你的/bin/sh是否指向 BusyBox：

$ file /bin/sh /bin/sh: symbolic link to busybox

同时确认/sbin/init也是 BusyBox 的 init 实现。

第二步：编写网络初始化脚本

创建/etc/init.d/S50network：

#!/bin/sh # S50network - 初始化网络并启动telnet服务 echo "Starting network setup..." # 设置静态 IP（根据实际网络调整） ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up # 添加默认网关（可选） route add default gw 192.168.1.1 # 启动 telnet 服务 echo "Launching telnetd..." telnetd -l root -p 23 & echo "Network and remote access ready."

赋予执行权限：

chmod +x /etc/init.d/S50network

第三步：注册到系统初始化流程

如果你使用的是传统 SysV 风格 init，编辑/etc/inittab，加入：

::sysinit:/etc/init.d/rcS ::respawn:/sbin/getty -L ttyS0 115200 vt100

其中rcS会调用/etc/init.d/S50network完成网络和服务启动。

⚠️ 注意：某些 Buildroot/Yocto 构建系统可能使用 systemd 或其他 init 方式，需对应调整启动机制。

登录体验也能优化？加个欢迎页更专业

虽然telnetd本身不支持 banner 显示，但我们可以通过 shell 的初始化脚本实现类似效果。

编辑/root/.profile（首次登录时会被/bin/sh自动加载）：

# .profile - 登录时执行的环境脚本 echo "" echo "==================================" echo " Embedded Debug Console" echo " Powered by BusyBox + telnetd" echo " 🔧 For development only!" echo "==================================" echo "" # 设置提示符，增强辨识度 export PS1='[\u@\h:\w]\$ '

再确认/etc/passwd中 root 的 shell 是/bin/sh：

root:x:0:0:root:/root:/bin/sh

下次 telnet 登录时，你会看到清晰的欢迎信息和定制化提示符，团队协作时再也不怕误操作别的设备。

实战中的那些“坑”与应对策略

❗ 问题一：telnet 能连上，但卡住不动？

常见原因：shell 没有正确启动，或者.profile脚本中有死循环/阻塞性命令。

✅ 解决方法：
- 改用sh -x .profile手动测试脚本逻辑
- 移除耗时操作（如 ping 外网）
- 确保每条命令都有超时控制

❗ 问题二：网络起来了，但 telnetd 没响应？

检查点：
- 是否已执行telnetd命令？
- 是否防火墙规则阻止了端口？
- 是否多个进程占用 23 端口？

✅ 排查命令：

netstat -tuln | grep :23 ps | grep telnetd

❗ 问题三：忘记关闭 telnetd，发布后被扫到了怎么办？

📌最佳实践建议：
- 开发阶段用 GPIO 按钮触发启动：长按某个按键才开启 telnetd
- 编译时通过宏控制是否包含 telnetd 功能
- 发布前统一清理/etc/init.d/下的调试脚本

例如：

#ifdef CONFIG_ENABLE_DEBUG_SHELL system("telnetd -l root -p 2323 &"); #endif

安全边界在哪里？这几点必须守住

尽管方便，但telnetd的使用必须划清红线：

✅允许的做法：
- 内网调试专用，配合交换机 VLAN 隔离
- 使用非标准端口（如 2323、8023）
- 结合 iptables 限制源 IP 访问
- 临时开启，调试完立即关闭

❌绝对禁止的行为：
- 暴露在公网环境
- 使用-i参数绕过认证
- 生产镜像保留空密码 root 账户
- 未记录登录行为，缺乏审计

小技巧：可以在启动脚本中加入日志记录：
sh logger -t telnetd "Remote debug service started at $(date)"

它真的过时了吗？不，它正活在调试一线

有人问：“现在都 2025 年了，还在用 Telnet？”

答案是：在正确的场景下，越简单的工具越强大。

想象一下：
- 你在调试一款基于 RISC-V 的工业控制器，Flash 只有 8MB；
- 新写的驱动导致 kernel panic，串口输出太快抓不住关键信息；
- 你把telnetd编进了 initramfs，重启后直接telnet 192.168.1.10，进系统一看dmesg，发现问题出在 I2C 时序配置……

这一分钟，省去了拆机、换线、重烧固件的半小时。

这就是BusyBox + telnetd的价值：在最关键的时刻，让你“连得上”。