小米路由器SSH开后怎么传文件？WinSCP连不上、scp报错，九成卡在协议这一步

帮同事那台刷了OpenWrt的AX3000T传去广告配置，WinSCP弹了一句「无法初始化SFTP协议。主机是SFTP服务器吗」。他在旁边急了：密码没错啊，SSH都能登进去。对，能登进去，但传文件是另一码事。

先搞清楚：SSH能登，不代表什么文件都能传

SSH是一条加密通道，敲 ssh root@192.168.31.1 登进去，用的就是这条通道本身。传文件是跑在通道里的另一种玩法，而且有两种互不兼容的玩法：一种叫SCP，年纪大、功能糙，本质就是「把文件原样抄过去」；另一种叫SFTP，是OpenSSH全家桶里后来加的正式服务，能列目录、能断点、能改权限，图形工具WinSCP默认走的就是它。

问题出在服务端。小米官方固件和OpenWrt用的都不是OpenSSH，是一个叫dropbear的轻量实现——嵌入式设备内存金贵，dropbear整个才几百K，OpenSSH动辄几兆，路由器扛不动那体格。dropbear只实现了SCP这一种传法，压根没有SFTP服务。你拿WinSCP默认的SFTP去敲一扇不存在的门，可不就报「主机是SFTP服务器吗」。

顺带说一句，这个报错跟密码对不对、端口开没开没有半点关系。密码错了提示的是Permission denied，协议不对才是这句SFTP的话。分清报错，能少走一半弯路：

想亲眼看一眼自家路由器跑的是不是dropbear，登进SSH敲 ps | grep dropbear，列表里跳出几个dropbear进程就是它了。小米官方固件和OpenWrt都认这个命，别纠结牌子。

WinSCP的正确连法：文件协议改一个字

WinSCP登录界面第一行「文件协议」，默认填的是SFTP。点开下拉框，选SCP，主机名192.168.31.1，端口22，用户名root，密码就是解锁SSH时拿到的那个。没解锁过的先去把SSH开了，官方通道在miwifi.com/miwifi_open.html页面拿root密码，新机型得走别的路子，这些我在解锁那篇里写全了。

传进去的文件，默认先扔/tmp目录。这是个讲究：/tmp是挂在内存里的临时盘，断电重启就清空，好处是读写飞快还不磨损闪存，坏处是别指望它替你保存东西。改配置、放固件包这类「用完就扔」的活放/tmp正合适，要长期留下的文件得挪去/data或者USB硬盘。

连上之后界面比SFTP模式朴素一点，没有目录缓存，进文件夹会顿半拍，但拖拽上传、右键改属性都在，日常改配置够用。两个小细节：一是连接时会弹一句关于「优化连接缓冲」的提示，选是或否都不影响使用；二是别勾「保存密码」，SSH密码这东西记在自己密码本里，比存在软件里踏实。

命令行党：scp后面加个-O

习惯命令行的，还有一个更隐蔽的坑，坑过不少人。2022年4月OpenSSH升到9.0，官方把scp命令的默认传输方式从传统SCP协议改成了SFTP。各家Linux发行版、新版macOS、Windows 11自带的ssh工具跟着全换了。结果就是：去年还能用的scp命令，今年对着路由器敲，报「subsystem request failed」，或者「sh: /usr/libexec/sftp-server: not found」——命令没变，协议换了，路由器那头还是没有SFTP。

解法是加一个参数，强制走老协议：

scp -O 文件名 root@192.168.31.1:/tmp/

这个-O就是OpenSSH 9.0专门留的退路，意思是用传统SCP协议。敲完这条，路由器的/tmp目录里就能看到文件了。嫌每次都要补-O，给自己加个别名 alias scp='scp -O'，一劳永逸。

拿不准自己电脑是不是新版，敲 ssh -V 看一眼版本号，9.0往上就中奖了。Windows 11这两年更新的自带工具、macOS 13以后的系统、各大Linux发行版2022年下半年的新版本，基本都在中奖范围里。报错信息也对得上号：老版报的错五花八门，新版清一色subsystem request failed，看到这句先想到-O，基本就对了。

传文件卡在半路不知道哪断了，加个-v参数：scp -O -v 文件 root@192.168.31.1:/tmp/，握手、认证、建通道每一步都打出来，卡在哪一行一眼看到，比干瞪眼强。

还有个不挑版本不挑协议的管道写法，怎么都通：cat 文件名 | ssh root@192.168.31.1 'cat > /tmp/文件名'。这条走的是纯SSH通道，连SCP都不沾，最笨也最稳，遇到百思不得其解的时候拿它兜底。

传大件别折磨SSH：路由器内存扛不住

SSH传文件这条路，适合的是几MB以内的小东西——配置文件、脚本、单个插件包。真往路由器里塞几十上百兆的东西，SSH不是干这个的。

两个原因。一是加密开销，scp全程加密，路由器那颗CPU要一边算加密一边搬数据，速率天生上不去。二是内存，scp在路由器那头要开缓冲区攒数据。手上这台AX3000T运行内存256MB，日常系统加插件占掉一截，剩下能匀给传输缓冲的本就不多；家里更老那批128MB的机器更紧张，系统一占所剩无几，传着传着缓冲吃紧，轻则越传越慢，重则进程被挤掉，表现就是传到一半莫名断开。我收过一台老固件的小米机，连几KB的小文件都传挂，翻日志一看就是内存那头的事。

还有个隐性代价容易被忽略：文件先落到/tmp再挪走的话，内存盘被大文件占满，路由器整个都会跟着卡，家里WiFi那几分钟发蔫，八成是有人正在往里塞大件。

大件走两条正路。一条是Samba共享：路由器USB口插上硬盘，后台把文件共享打开，电脑里敲 \\192.168.31.1 直接挂成网络盘，实测读写几十MB每秒，比SSH快出一个量级，整套设置在USB接口那篇里写过。另一条更原始：U盘物理插拔，拷完插到路由器上，刷机党传固件包基本都这么干，刷OpenWrt那篇里的固件就是这么进去的。

哪些活该走SSH传，一张表分清

表里第五行多说一句，有人拿SSH往路由器挂的硬盘里备份相册，想法是好的，但相册这种持续大写入的活，Samba挂载都比SSH强，真要自动化还是NAS的事。

还有个判断土办法：传文件之前先想想这东西「要不要长住」。改完就生效、重启就作废的配置，走SSH扔/tmp最快；要一直待在路由器里的东西，从Samba那头挂硬盘进去，路径、权限、速度三样都省心。我后来跟同事定的规矩更糙：超过一个MP3大小的，一律不给走SSH，简单粗暴但从没再断过。

卡住的时候按这个顺序过

这套顺序是我和同事那台机器上磨出来的，当天从WinSCP换协议到scp加-O，前前后后折腾了小半个钟头，回头整理才发现其实就三步。
第一步，先确认SSH本身能登，敲 ssh root@192.168.31.1，能登进去说明密码、端口、网络全对；第二步，WinSCP报SFTP的错就换SCP协议，命令行报subsystem的错就加-O；第三步，都通了还断线，看一眼文件大小，超过十来兆就别较劲了，换Samba或者U盘。真把系统折腾坏了，那是救砖的活，不归传文件管。三步下来，这事的坑基本见底了。说到底SSH是进门的钥匙，不是搬家的卡车，小东西它拎得动，大家伙交给专门拉货的，谁都不累。