Brother Scan to SFTP: Receipts Straight Into a Hetzner Storage Box
A Brother MFC scans receipts via SFTP into a Storage Box sub-account. Port 22 vs 23, RFC4716 keys, reachability and the firmware update that fixed it.
An office I look after has a Brother MFC-L6910DN. The goal was simple. Someone puts a stack of receipts on the feeder, presses one button, and the PDF lands in the inbox of my receipt sorter. No mail in between, no USB stick, no "I'll send it later".
The target is a Hetzner Storage Box sub-account over SFTP. Scan-to-mail for the people in the office came along on the same day. It took longer than it should have, and the last fix was not where I was looking.
TL;DR: Reset the printer's network settings if you can't log into the web UI, but photograph the settings first. Let the printer make its own key pair and put the public key into the sub-account's .ssh/authorized_keys. On a Storage Box, port 23 wants OpenSSH format and port 22 wants RFC4716 format, so put the key in both. Turn on external reachability for the sub-account. If it still fails with a correct key, update the printer firmware. 1.20 to 1.43 fixed it for me.
The quick tests first
These are the commands I ended up running again and again. Example values: sub-account u123456-sub3, printer at 192.168.1.50.
# can the office network reach the Storage Box at all?
nc -vz u123456.your-storagebox.de 22
nc -vz u123456.your-storagebox.de 23
# does the Storage Box accept a key? test from a normal machine
sftp -P 23 -i ~/.ssh/test_key u123456-sub3@u123456.your-storagebox.de
sftp -P 22 -i ~/.ssh/test_key u123456-sub3@u123456.your-storagebox.de
Port 23 timed out from the office. Port 22 was open. That one result decided half of the setup.
Step 1: get into the printer
I couldn't log into the web admin. The default password didn't work, the one on the sticker didn't work either. Either someone had changed it, or the printer had locked the login after too many failed tries. I don't know which.
The fix was a network reset from the touch panel on the printer. After that the sticker password worked.
Before you do that: take photos of the TCP/IP page and the mail settings. The reset wipes them. In my case the IP stayed the same because it comes from DHCP. If yours is static, you'll be typing it back in from the photo.
After the reset the browser shows "not secure" for the web UI. The printer made a new self-signed certificate. That's harmless, it's a printer on the LAN.
Step 2: scan to mail over SMTP
The printer sends through my own mail server as an SMTP client:
| Setting | Value |
|---|---|
| SMTP server | mail.example.com |
| Port | 587 |
| Auth | SMTP-AUTH, user scan@example.com |
| Encryption | TLS |
| Verify server certificate | off |
The certificate check had to go. The printer firmware didn't know ISRG Root X1, the Let's Encrypt root, so the TLS handshake failed. The cleaner way is to import that CA certificate into the printer. Turning off the check works too, the connection is still encrypted, it just doesn't verify who it's talking to.
The test mail was accepted. Then the scan mails landed in spam. The sending domain had no SPF and DKIM yet. That's still open on my list. If you want to fix it properly, I wrote down the full order in SPF, DKIM and DMARC from zero.
Step 3: keys for SFTP
The SFTP profile on the Brother uses public-key auth. You don't bring your own key. The printer generates its own client key pair in the web UI, RSA 2048 in my case. You export the public key and put it on the server.
Two things go in two directions:
- Printer public key → Storage Box. Into
.ssh/authorized_keysof the sub-account. - Storage Box host key → printer. The printer wants to know the server's host key, so you import it in the SFTP settings.
How I put the key onto the sub-account: SFTP in from a machine that works, create .ssh if it's not there, upload authorized_keys. If you've never handled key files by hand, the basics are in Linux users and SSH keys.
Gotcha: port 22 and port 23 want different key formats
This is the Storage Box part that cost me time.
- Port 23 is SSH with an OpenSSH-style SFTP server. It wants the normal OpenSSH key line in
authorized_keys. - Port 22 is SFTP through ProFTPD's
mod_sftp. That one wants the key in RFC4716 format.
The office firewall blocks outbound port 23. So the printer has to use port 22, so the key has to be in RFC4716 format. I put the key in both formats, so it works on both ports. Convert it like this:
ssh-keygen -e -f printer.pub > printer.rfc4716
-e exports the OpenSSH public key to RFC4716. The authorized_keys then looks like this (placeholder key, shortened):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7exampleexampleexample... brother-printer
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA, brother-printer"
AAAAB3NzaC1yc2EAAAADAQABAAABAQC7exampleexampleexample...
...
---- END SSH2 PUBLIC KEY ----
Check what format the printer actually exported. If it's already RFC4716, go the other way with ssh-keygen -i -f printer.rfc4716 to get the OpenSSH line.
Gotcha: external reachability is off on the sub-account
Even with the key right, I got auth errors from outside. The sub-account had "external reachability" switched off. That means it only answers from inside Hetzner's network. From the office it just looked like a bad login.
Turn it on in the Storage Box panel, in the sub-account settings. It's easy to miss because the main account works fine from everywhere.
Gotcha: it was the firmware
Key in both formats, reachability on, port 22 open. The printer still got auth errors.
So I took the printer out of the picture. I made a throwaway key on another machine, put it into the same authorized_keys, and logged in with sftp -P 22. Worked. So the Storage Box side was fine, and the problem was the printer.
The printer was on firmware 1.20. I updated to 1.43. After that SFTP worked on the first try with the same key and the same settings.
I can't tell you what exactly changed between those versions. I didn't dig. The lesson I took: once you've proven the server side with a different client, stop editing authorized_keys and look at the device. Old firmware with old SSH code is a normal thing on printers.
While testing I had also added a DSA key at some point. I removed it afterwards. Clean up your test keys, they don't belong in there.
Where the scans go
The SFTP target folder on the printer is just /. For the sub-account that is its own root, and on the main box that maps to an inbox folder. The receipt sorter runs every 10 minutes, picks up whatever is in there and files it. How that sorter deals with amounts and why I don't let the AI parse statements is in my AI receipt sorter post.
That's why I like a sub-account for this. The printer only sees its own folder, nothing else on the box. If the printer gets compromised or someone reads the key out of it, they can drop files into one inbox. Not great, but not the archive either. Scans arriving more than once are no problem as long as your pipeline is idempotent.
For people in the office who want to click through the filed receipts in Explorer, I map the main box as a drive. That's Storage Box as a Windows network drive.
The home screen
Last step, and the one people actually notice. On the printer home screen:
- one one-touch tile per person for scan-to-mail
- one tile "receipts" for the SFTP profile
- the Fax tile removed, because fax was never set up
Nobody has to pick a profile from a list. Receipt on the feeder, press "receipts", done.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Web admin rejects default and sticker password | Password changed or login locked | Network reset on the touch panel, photograph settings first |
| Browser says "not secure" after reset | New self-signed cert on the printer | Ignore, it's the LAN |
| SMTP test fails on TLS | Printer doesn't know ISRG Root X1 | Import the CA cert, or turn off "verify server certificate" |
| Scan mails go to spam | No SPF/DKIM for the sending domain | Set up SPF, DKIM, DMARC |
nc -vz ... 23 times out |
Office firewall blocks outbound 23 | Use port 22 |
| Auth error on port 22, key looks right | Key only in OpenSSH format | Add the RFC4716 version (ssh-keygen -e) |
| Auth error from outside, works from Hetzner | External reachability off on sub-account | Turn it on in the panel |
| Throwaway key works, printer still fails | Old printer firmware | Firmware update (1.20 → 1.43 here) |
What I'd do next time
Firmware update first, before touching any key. Then nc -vz on both ports from the office, so you know which key format you need before you start. Put the key in both formats anyway. Check external reachability on the sub-account. And prove the server side with a second client before you blame the server.