Security / 3D Printing

Harden Your QIDI Plus 4 Before It Touches Your Network

A QIDI Plus 4 is a small Linux computer running Klipper, Moonraker and a Fluidd web UI. So is most any modern fast printer. 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. An open camera stream. None of that is exotic. It is just defaults. This is the 20-minute lockdown, with the exact commands and the traps that make a naive attempt look like it worked when it did not. Everything here applies to any Klipper or Moonraker printer, not just QIDI.

BE WARNED: back up your config first. Everything below is reversible and low-risk. Copy the Klipper config off the machine anyway, before you touch a printer. On QIDI and MKS boards that is ~/printer_data/config/. It holds printer.cfg, moonraker.conf, your macros, and 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:

SSH. Accepts passwords, permits direct root login, and offers some dated crypto.
Moonraker, the API on 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. Network isolation contains everything else.

Step 1: change the default password

The factory SSH login is a published default, identical across units. Anyone who has touched one of these before knows it. So does anyone who can search for thirty seconds. Change it first. SSH in. The default user on QIDI and MKS boards is mks. Then:

sudo passwd mks

BE WARNED: passwd needs a real terminal. Run it through a wrapper that does not allocate a TTY and it fails with Authentication token manipulation error and changes nothing. That covers non-interactive one-liners and some automation shells. Run it from an 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 log in with a key, password authentication is pure attack surface. It is what makes the default password, 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 before you disable passwords. Run ssh -i ~/.ssh/id_ed25519_printer mks@<printer-ip> hostname. Skip that and a mistake locks you out to the touchscreen. Then edit /etc/ssh/sshd_config so these three directives are set. Replace the existing lines, do not append. 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. The companion fleet-wide SSH hardening guide has the same fix at scale.

BE WARNED: the obvious "is the weak-crypto fix working?" test lies. Connect while forcing a weak MAC, expect rejection, and it often succeeds anyway. Modern SSH negotiates an AEAD cipher, ChaCha20-Poly1305, which carries its own integrity and ignores the MACs list entirely. Force a non-AEAD cipher so the MAC actually gets negotiated:

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

Then verify the wins that matter. Your key still logs in. A password attempt is now refused with Permission denied (publickey).

Step 3: put it on its own network segment

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

Here is why it matters. A compromised printer is not just a privacy problem, though the open camera is exactly that. It is 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 turns the easiest target in the house into a contained one.

Step 4: stop Moonraker trusting your whole LAN

Moonraker's shipped config trusts the entire private-address range. Every phone, laptop, TV and smart-plug on a flat network can drive the printer's API with no login. Upload and start G-code, run macros. In ~/printer_data/config/moonraker.conf, narrow trusted_clients to just the hosts you actually print from. 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 with sudo systemctl restart moonraker. Any other device now gets a login prompt, 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. Anything that can reach the printer can watch it. On an isolated segment that stays contained to the segment. Never port-forward the web UI or the 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 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. Firmware updates do not modernize the base OS. They update the printer app and the touchscreen, not the kernel underneath. That is exactly why isolation matters. You are mitigating an OS you cannot easily patch. The QIDI Plus 4 security review has the full teardown of what runs under the hood.

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 and 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 or IoT network.
Narrow Moonraker's trusted_clients. Keep force_logins on.
Never port-forward the web UI or the camera. Use a VPN for remote access.

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