The Restricted Shell, now editable from your dashboard - plus Ubuntu 24.04 support

Two things landed in this update, and they are both about the same idea: giving you real control over your server without sending you back to the terminal. QuickBox Pro now installs on Ubuntu 24.04, and the restricted shell that quietly keeps your standard users in their lane is now something you can shape yourself, right from the dashboard, with Fail2Ban watching its back.

QuickBox Pro now installs cleanly on Ubuntu 24.04 LTS (Noble Numbat). It joins the supported lineup next to Debian 13 (Trixie), which is our recommended default, Debian 12 (Bookworm), and Ubuntu 22.04 LTS (Jammy). If you have been holding a fresh box on 24.04 waiting for the green light, this is it.

As always, install onto a clean, freshly provisioned server rather than an existing setup. Full requirements and the step-by-step walkthrough live in the Getting Started guide.

Every standard seedbox user on your server runs inside a restricted shell. It is what lets someone manage their own torrents and files without being able to wander the rest of the machine, chain commands together, or drop into a full interactive shell. It has always been there doing its job quietly in the background.

What is new is that you no longer have to SSH in and hand-edit a config file to tune it, and you no longer lose those edits the next time you run qb update. There is now a proper Restricted Shell editor in the dashboard, at Settings > Security > Restricted Shell, and it is the recommended way to manage that policy.

The old way had a nasty edge to it: you would carefully edit /etc/lshell.conf over SSH, get it just right, and then the next update would re-copy the shipped config straight over your changes. The new editor stores your edits in the shared database instead, so on every update QuickBox lays down the clean base config and then re-applies your changes on top automatically. Your policy sticks.

The editor exposes the ten user-facing fields of the policy as guarded form inputs, so you get sensible controls instead of a raw config file:

• ●Allowed commands - the whitelist of what a limited user may run
• ●Forbidden patterns - the tokens that stay blocked everywhere, like command chaining, piping, redirection, and sudo
• ●Over-SSH commands - what is allowed through non-interactive SSH, for things like a remote rsync
• ●SCP and SFTP - whether file transfer is permitted
• ●Warning counter - how many forbidden commands a user gets before the session is cut
• ●Max processes - a per-user process cap that quietly contains fork bombs
• ●Intro banner - the welcome text your users see when they log in
• ●Aliases - command shortcuts you want available

Every input carries the same guard rails the server enforces on save, so the hints you see in the form are exactly what will actually be accepted. You cannot, for example, slip an interactive shell like bash or a shell-escape editor like vim into the Allowed list, because that would defeat the whole point of a restricted shell. The editor turns those away.

A handful of fields are always rendered from the shipped base and cannot be overridden - the log paths, the path confinement that keeps a user inside their own home directory, and the no-exec backstop. These are what actually hold the sandbox together, and, as you will see in a moment, they are also what let Fail2Ban watch the shell for abuse. If one of those ever gets sent as an override, the whole request is rejected rather than quietly accepted. It is a deliberate line we do not let anyone cross, including a hand-edited config.

This is the part we care about most, because a broken restricted-shell config would lock every standard user out of their own account.

• ●Preview before you commit. A Preview action shows you the current policy next to the proposed one and lists exactly which fields changed. Nothing is written until you have seen the diff.
• ●Validated the way lshell reads it. Before the live config is ever replaced, the proposed policy is serialized and parsed exactly the way the restricted shell parses it. If it fails that check, your live config is left completely untouched and you get the errors instead.
• ●Revert one field at a time. Changed your mind about a single setting? Reset just that field back to the shipped default without disturbing the rest of your policy.
• ●Admin only, and change-protected. Viewing and editing the policy sit behind the standard Security Settings permissions, and every save is protected against cross-site request forgery.
• ●Nobody gets kicked mid-session. Users who are already connected keep the previous policy for the rest of their session. Your changes take effect for each user the next time they log in.

Here is where it gets genuinely useful. The restricted shell does not just block a forbidden command - it writes a line to its own log every time a confined user trips a rule. On its own, that is just a record. But if you have Fail2Ban installed, QuickBox ships two shell-confinement jails that read those logs and turn repeated abuse into a ban.

They come in two tiers, tuned so normal fumbling never costs anyone a ban:

• ●The everyday jail watches for forbidden commands and warnings, and it is deliberately forgiving. One fat-fingered command will not ban anybody - it takes a real, repeated pattern.
• ●The serious jail watches for the events that only happen when someone is genuinely pushing on the walls: getting kicked out, tripping the process cap, or blowing past a command timeout. That one bans on first sight.

You manage both from the Fail2Ban tab under Settings > Security, in the Application and Security Jails panel, with a per-jail toggle. It is opt-in and off by default, so you decide when to arm it.

A couple of honest touches worth knowing about:

• ●You may sometimes see a jail show up as enabled but awaiting activity. That is us being straight with you rather than showing a green light that is not earned. The jail is armed, but Fail2Ban only truly starts once there is a log for it to watch, and the restricted-shell log does not exist until one of your limited users actually does something. The moment that happens, the jail goes live on its own. There is nothing for you to fix.
• ●If you are running an older install that predates these jails, the panel shows a "set up monitoring" action that wires everything in for you. No config surgery required.

Prefer the terminal for this part? The jails answer to the CLI too, with qb manage fail2ban -o lshell-enable, -o lshell-disable, and -o lshell-status for a quick state check with live ban counts.

Update your server, then head to Settings > Security > Restricted Shell to shape the policy, and the Fail2Ban tab to arm the shell jails. Everything is written up in full:

• ●Restricted Shell Policy - every field, every guard rail, and the update-survival details
• ●Fail2Ban - the full jail control center, including the shell-confinement jails
• ●Security Settings - the parent page for everything under Settings > Security
• ●Getting Started - install requirements, including the new Ubuntu 24.04 support

As always, if you get stuck or just want to talk it through, we are in Discord.