How do you transfer files after turning on SSH on a Xiaomi router? WinSCP can't connect, SCP gives errors—90% of the time it's stuck at the protocol stage

sent ad configurations for a colleague's AX3000T that had been flashed with OpenWrt, WinSCP popped up a message: "Unable to initialize SFTP protocol. Is the host an SFTP server?" He got anxious beside him: The password is correct, SSH login is possible. Yes, you can log in, but sending files is a different matter.
clarify first: SSH Noden doesn't mean you can transfer every file
SSH is an encrypted channel. Typing ssh root@192.168.31.1 to log in uses this channel itself. Transferring files is another way to run through the passage, and there are two incompatible methods: one is called SCP, which is old and crude, essentially 'copying files as they are'; The other is called SFTP, a formal service added later to the OpenSSH suite. It can list directories, break points, and change permissions. The graphics tool WinSCP defaults to this feature.
problem lies on the server side. Xiaomi's official firmware and OpenWrt don't use OpenSSH; it's a lightweight implementation called dropbear—embedded device memory is precious, dropbear alone costs only a few hundred kilometers, OpenSSH can easily reach several megabytes, and routers can't handle that size. dropbear only achieves SCP transmission; there is no SFTP service at all. If you use WinSCP's default SFTP to knock on a door that doesn't exist, you'll just get a message of 'Is the host an SFTP server?'
By the way, this error has nothing to do with whether the password is correct or whether the port is open. If the password is incorrect, the message is 'Permission denied'; if the protocol is incorrect, then this SFTP message is correct. Distinguishing errors clearly can save half the way in the loop:
| error in the original message | the root of the disease | how to fix it |
| Permission denied | password incorrect | return to the unlock page to retrieve the root password again |
| Connection refused | 22 if the port is not open or SSH is not unlocked | complete the SSH step first |
| cannot initialize the SFTP protocol | choosing the wrong protocol means the router lacks this service | so the file protocol is replaced with a SCP |
| subsystem request failed | new SCP is removed by default SFTP | and a -O |
want to see for themselves whether their router is running a dropbear, log into SSH and tap ps | grep dropbear, and a few dropbear processes pop up in the list—that's it. Xiaomi's official firmware and OpenWrt are both accepting this fate, so don't get hung up on the brand.
WinSCP Linking: Change the Document Agreement by One Character
WinSCP the first line of the login interface, "File Agreement," the default is SFTP. Open the dropdown menu, select SCP, hostname 192.168.31.1, port 22, username root, and the password you get when unlocking SSH. If you haven't unlocked it before, first enable SSH. The official channel requires the root password on the miwifi.com/miwifi_open.html page. New models need to use other routes. I covered all of this in the unlocking article
files you send in, by default, the /tmp directory is thrown in. Here's a tip: /tmp is a temporary drive attached to memory—just wipe it out and restart after power-off. The advantage is fast read/write speeds without wearing out the flash, but the downside is don't expect it to save your things. Configure settings or install firmware packages like 'throw away after use' and /tmp are just right. Files that need to be kept long-term should be moved to /data or USB hard drives.
After connecting, the interface is simpler than SFTP mode, with no directory cache, folders lag in half a beat, but drag-and-drop uploads and right-click attribute changes are all present, making daily configuration changes sufficient. Two small details: First, a prompt about "optimizing connection buffer" pops up when connecting; choosing to do so does not affect usage; Second, don't check "Save password"—keeping SSH passwords in your own password book is more reliable than storing them in software.
Command Party: Add a -O
after the SCPis used to command lines, but there's an even more hidden pit that has tricked quite a few people. In April 2022, OpenSSH was upgraded to 9.0, and the official system changed the default transmission method for SCP commands from the traditional SCP protocol to SFTP. All Linux distributions, newer macOS, and Windows 11 built-in SSH tools have all been replaced accordingly. The result was: the scp command that worked last year is now being typed on the router this year, reporting "subsystem request failed" or "sh: /usr/libexec/sftp-server: not found"—the command hasn't changed, the protocol has changed, and the router still doesn't have SFTP.
solution is to add a parameter and force the old protocol:
scp -O filename root@192.168.31.1:/tmp/
this -O is a dedicated fallback in OpenSSH 9.0, meaning it uses the traditional SCP protocol. After typing this, you can see the file in the router's /tmp directory. If you want to add -O every time, add a nickname alias scp = 'scp -O' for a one-time solution.
you're not sure if your computer is new, just type ssh -V to check the version number, and if you go above 9.0, you're in the jackpot. Windows 11 comes with built-in tools updated over the past two years, macOS 13 and later, and major Linux distributions released in the second half of 2022—basically all within the winning range. The error information also matches the number: the old version made all kinds of errors, and the new version is all subsystem request failed. When you see this sentence, first think of -O, which is basically correct.
file gets stuck halfway and breaks somewhere. Add a -v argument: scp -o -v file root@192.168.31.1:/tmp/. Every step of handshake, authentication, and channel setup is typed out. Seeing exactly where the stuck line is is better than staring blankly.
there's also a pipeline method that doesn't care about version or protocol—no matter how you go, it works: cat Filename | ssh root@192.168.31.1 'cat > /tmp/filename'. This one uses a pure SSH channel, doesn't even touch SCPs, is the dumbest but also the safest, and when you run into something confusing, use it as a backup.
: router memory can't hold up
SSH file transfer is suitable for small items within a few MB—configuration files, scripts, individual plugin packages. Really putting tens or hundreds of megabytes into the router—SSH isn't for this.
two reasons. First, encryption overhead: SCP encrypts the entire process, and the router's CPU has to compute encryption while moving data, so the speed naturally can't be high. Second, memory: the SCP needs to open a buffer on the router's end to store data. The one I have has 256MB of AX3000T RAM, but the system and plugins take up a portion of daily use, leaving little to allocate for transfer buffering; The older batch of 128MB machines at home is even more stressful, with almost no system left. The buffering tightens as you transfer, sometimes slowing down as you transfer, sometimes getting squeezed out of the process, causing sudden disconnections halfway through. I once received a Xiaomi phone with old firmware that even had a few KB of small files transferred. Checking the logs clearly showed it was on the memory side.
there's another hidden cost that's easy to overlook: if files are stored in /tmp first and then removed, the memory will be filled with large files, the router will lag along with it, and the WiFi at home will wilt for a few minutes—chances are someone is stuffing in large items.
big items follow two main paths. One is Samba sharing: plug the router's USB port into the hard drive, open file sharing in the background, and type \\192.168.31.1 directly on the computer to attach it to the network drive. Actual read/write speeds are tens of MB per second, an order of magnitude faster than SSH. entire setup is in the USB interface section. Another more primitive method: physically plug and unplug the USB drive, then copy it and plug it into the router. Flashing enthusiasts usually do this for firmware packages. the firmware in the OpenWrt is exactly like this.
which ones deserve to go through SSH transmissions, one table tells them apart
| want to transmit | which path should | why |
| a few KB of conf configuration | SSH + SCP protocol__ Send in HTML130__ | seconds, modify immediately |
| several MB of plugin package | SSH + SCP protocol | /tmp can fit inside, and you can install it once you enter |
| flashing firmware | U several tens of megabytes is mainly the USB drive, and the SCP Assistant | Breed is designed specifically for USB drives |
| hundreds of megabytes of files | Samba the encryption and memory of shared | SSH can't handle |
| backup of the entire album | Don't use a router—the NAS | positioning doesn't match |
one more thing on the fifth line of the table: some people use SSH to back up albums to the hard drive connected to the router. It's a good idea, but for tasks like the album that require continuous big writing, Samba mounting is better than SSH. If automation really comes down to the NAS, that's the case.
there's another trick to judge: before sending documents, consider whether the item "needs to be stayed long-term." Configurations that take effect after modification and become obsolete upon reboot—using SSH and throwing /tmp is the fastest; Anything that stays in the router all the time can be connected via Samba, making paths, permissions, and speed worry-free. Later, my colleagues and I set even rougher rules: anything larger than one MP3 file is never allowed to use SSH—simple and blunt, but never interrupted.
stuck in this order
this sequence was honed on the machine my colleague and I had. That day, from switching protocols in WinSCP to SCP plus -O, it took nearly half an hour of messing around. When I sorted it out, I realized it was actually just three steps.
Step one: First, confirm that SSH is supported. Typing ssh root@192.168.31.1, being able to log in means the password, port, and network are all correct; Step two: When WinSCP reports an SFTP error, switch to the SCP protocol; when the command line reports a subsystem error, add -O; Step three: Even if it's connected, disconnect the cable. Check the file size—if it's over ten megapixels, don't argue—switch to Samba or USB drive. really messed up the system, was a brick-saving job, not file transfer control. After three steps, the pitfall in this matter was basically over. Ultimately, SSH is the key to entry, not a moving truck. It can carry small items, and the big parts are handed over to those who specialize in hauling goods, so no one gets tired.
