Security / 3D Printing

Harden Your QIDI Plus 4 Before It Touches Your Network

A QIDI Plus 4 — like most modern fast printers — is a small Linux computer running Klipper, Moonraker, and a Fluidd web UI. It ships configured for "works instantly on any network," not "safe on any network": a published default SSH password, a web API that trusts your whole LAN, and an open camera stream. None of that is exotic; it's just defaults. Here's the 20-minute lockdown, with the exact commands and the traps that make a naive attempt look like it worked when it didn't. Everything here applies to any Klipper/Moonraker printer, not just QIDI.

Back up your config first. Everything below is reversible and low-risk, but before you touch a printer, copy its Klipper config off the machine. On QIDI/MKS boards that's ~/printer_data/config/ (holds printer.cfg, moonraker.conf, your macros, and — critically — your calibration in saved_variables.cfg). One scp -r mks@<printer-ip>:printer_data/config ./qidi-config-backup and you have a rollback point for the whole afternoon.

What you're actually locking down

The printer runs a real SSH server and a couple of network services. As shipped, the notable ones are:

SSH — accepts passwords, permits direct root login, and offers some dated crypto.
Moonraker (the API, port 7125) — its default config marks your entire private network as "trusted," so any device on your LAN can drive the printer with no login.
The webcam stream (mjpg-streamer) — served openly, no authentication.

Fix them in this order — the first two neutralize the biggest risk, and network isolation contains everything else.

Step 1 — Change the default password

The factory SSH login is a published default that's identical across units — anyone who has touched one of these before, or can search for thirty seconds, knows it. Change it first. SSH in (the default user on QIDI/MKS boards is mks), then:

sudo passwd mks

Gotcha: passwd needs a real terminal. If you run it through a wrapper that doesn't allocate a TTY (a non-interactive one-liner, some automation shells), it fails with Authentication token manipulation error and changes nothing. Run it from an actual interactive SSH session, or force a TTY with ssh -t. Save the new password in your password manager.

Step 2 — Set up SSH keys, then turn off password login

Once you're logging in with a key, password authentication is pure attack surface — it's what makes the default (or any) password remotely brute-forceable. From your workstation:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_printer -C "printer"
ssh-copy-id -i ~/.ssh/id_ed25519_printer.pub mks@<printer-ip>

Confirm the key works (ssh -i ~/.ssh/id_ed25519_printer mks@<printer-ip> hostname) before disabling passwords — otherwise a mistake locks you out to the touchscreen only. Then edit /etc/ssh/sshd_config so these three directives are set (replace the existing lines rather than appending — sshd uses the first value it finds for each keyword, so a duplicate at the end of the file does nothing):

PasswordAuthentication no
PermitRootLogin prohibit-password
MACs hmac-sha2-256,hmac-sha2-512,[email protected],[email protected]

Validate and reload without dropping your current session:

sudo sshd -t && sudo systemctl reload ssh    # 'reload' keeps existing connections alive

The MACs line drops weak MAC algorithms (like hmac-sha1) that a vulnerability scan will otherwise flag — see the companion fleet-wide SSH hardening guide for the same fix at scale.

Gotcha: the obvious "is the weak-crypto fix working?" test lies. Connecting while forcing a weak MAC and expecting rejection often succeeds anyway — because modern SSH negotiates an AEAD cipher (ChaCha20-Poly1305) that carries its own integrity and ignores the MACs list entirely. You have to force a non-AEAD cipher for the MAC to actually get negotiated:

ssh -o Ciphers=aes256-ctr -o MACs=hmac-sha1 mks@<printer-ip>
# correct result: "Unable to negotiate ... no matching MAC found"

And verify the wins that matter: your key still logs in, and a password attempt is now refused (Permission denied (publickey)).

Step 3 — Put it on its own network segment

This is the highest-leverage move, and it's the one that contains everything you don't lock down. Drop the printer onto its own VLAN or your router's IoT/guest network, firewalled off from your main devices, and open a path only from the one machine you slice from. See the VLAN isolation guide for the zone-based-firewall specifics (including a gotcha where a block rule silently eats return traffic if you don't scope it by connection state).

Why it matters: a compromised printer isn't just a privacy problem (though the open camera is exactly that). It's a full Linux foothold on your network — an always-on box that can scan and pivot — running an OS the vendor no longer patches. Segmentation is what turns "the easiest target in the house" into "contained."

Step 4 — Stop Moonraker trusting your whole LAN

Moonraker's shipped config trusts the entire private-address range, which means every phone, laptop, TV, and smart-plug on a flat network can drive the printer's API — upload and start G-code, run macros — with no login. In ~/printer_data/config/moonraker.conf, narrow trusted_clients to just the host(s) you actually print from, and leave force_logins on so everything else has to authenticate:

[authorization]
force_logins: True
trusted_clients:
    127.0.0.0/8
    <your-workstation-ip>/32
cors_domains:
    https://app.fluidd.xyz
    https://my.mainsail.xyz

Restart Moonraker (sudo systemctl restart moonraker) and you'll get a login prompt from any other device — which is the point.

Step 5 — Don't expose it to the internet, and lock the camera down

The webcam stream has no authentication of its own, so anything that can reach the printer can watch it. On an isolated segment that's contained to that segment; the thing to never do is port-forward the web UI or camera straight to the internet. If you need remote access to your printer, put it behind a VPN or an authenticated tunnel — not a naked port-forward. (Building a printer status/connection page? Keep it read-only and outside the trust boundary.)

The one thing you can't fix this way: these printers ship on an old, frozen Linux image (the Plus 4 is Debian 10, end-of-life since mid-2024), and firmware updates don't modernize the base OS — they update the printer app and touchscreen, not the kernel underneath. That's exactly why isolation matters: you're mitigating an OS you can't easily patch. For the full teardown of what's running under the hood and why, see the QIDI Plus 4 security review.

The 20-minute checklist

Back up ~/printer_data/config/ off the machine.
Change the default password.
Add an SSH key; confirm it works; then set PasswordAuthentication no + PermitRootLogin prohibit-password + a SHA-2-only MACs line.
Verify: key logs in, password refused, weak MAC rejected (with a forced non-AEAD cipher).
Move the printer to an isolated VLAN / IoT network.
Narrow Moonraker's trusted_clients; keep force_logins on.
Never port-forward the web UI or camera; use a VPN for remote access.

Twenty minutes, no hardware, all reversible — and the machine goes from "the easiest target on the network" to a properly boxed-in appliance.