SSH access and resource limits

Where these live

Both are settings on a hosting package: Admin → Packages, then create or edit a package. Every account on that package gets them, and a change applies straight away to every account already on it. Both work on every tier, Community included.

SSH access

The SSH access switch decides whether accounts on the package can log in over SSH. It is off by default. Leave it off unless you trust those customers with a shell: SSH gives them a real login on the server as their own account (not root), able to run anything their account can.

What the customer does

1. In the customer panel, open SSH Keys and add a public key. Both the OpenSSH format (ssh-ed25519 AAAA… name) and the PuTTY format (the block PuTTYgen shows, starting ---- BEGIN SSH2 PUBLIC KEY ----) are accepted. Private keys, DSA keys and RSA keys shorter than 2048 bits are refused.
2. The same page shows how to connect: the exact ssh command, and the Host Name, Port and Login-as values for PuTTY. The login name is the account's username, not root: a key added here only works for that account. Pasting a key's fingerprint (SHA256:…) by mistake gets an explanation of where the real key is.

Key, password, or both

From 1.9.7 the customer chooses How you log in on the same page: Key only (the default), Password only, or Key or password. Choosing a password method asks for an SSH password of at least 12 characters, separate from the panel password. The panel sets it up for that account only, in its own file under /etc/ssh/sshd_config.d/, checked with sshd -t before it takes effect. You can stop hosting accounts using passwords on the Server SSH page; accounts that use one then go back to keys.

If the package does not include SSH, the page says so and the login is refused. Keys added in the meantime are kept and start working as soon as you switch SSH on for the package.

What turns it off

• The package. Switching SSH off, or moving the account to a package without it, removes access and ends any open SSH sessions.
• Suspension. A suspended account cannot log in over SSH; access comes back on unsuspend.
• No package. An account with no package has no SSH access.

SFTP runs over SSH, so it follows the same switch. Plain FTP accounts are separate and are not affected. The terminal inside the customer panel does not use SSH either, so it keeps working whatever this switch says. Your own root login over SSH is never touched: the panel only blocks hosting accounts it manages.

Server SSH: root and password logins

Admin → Server → Server SSH (1.9.7) manages SSH for the server itself:

• Root's SSH keys. Add or remove keys that can log in as root. They go into a marked section of /root/.ssh/authorized_keys; keys your hosting provider or you added by hand are kept as they are.
• Root login: password or key, key only (PermitRootLogin prohibit-password), or off. Key only is refused until root has at least one key, and the page asks you to test it in a new window first.
• Password logins: allowed or keys only (PasswordAuthentication no) for the server's other users.
• Hosting accounts may use a password: whether customers can choose a password login.

The panel never edits /etc/ssh/sshd_config. Its settings live in its own files in /etc/ssh/sshd_config.d/, each change is checked with sshd -t and undone if anything looks wrong, and open sessions are never dropped. The panel's own Terminal does not use SSH, so it keeps working whatever you choose here.

Command-line PHP version

From 1.9.7, customers choose the PHP version that runs when they type php in SSH or the Terminal, and in their cron jobs and background workers: PHP Settings → Command-line PHP. It applies to the whole account, since one account can have sites on different versions. Background workers are restarted to pick it up. Deploys always use the site's own PHP version.

Private home folders

Every customer's home folder (/srv/sites/<user>) is private to that customer. Other accounts on the server cannot list or read it, which matters most once customers have a shell. The web servers and the panel keep exactly the access they need to serve the sites and manage the files.

Unlimited package limits

The counts on a package (sites, domains, subdomains, databases, emails, FTP accounts, cron jobs) each have an ∞ button that makes that limit unlimited. A count of 0 still means none allowed. Disk quota and bandwidth are unlimited when left empty or set to 0.

Resource limits

The Resource limits section of a package sets three caps per customer. Each one is unlimited when left empty or set to 0, which is the default.

• CPU limit (%): 100% is one full CPU core, 200% two cores, and so on. A customer at the cap is slowed down, not stopped.
• Memory limit (MB): the customer's processes are slowed as they near the limit, and the process using the most memory is stopped if they go over it.
• Max processes: processes and threads together. At the cap, starting another one fails, which is what stops a runaway script or a fork bomb.

What the limits cover

• the customer's Node and Python apps and background workers
• the terminal in the customer panel
• deploy builds and custom deploy commands (builds also stop after 30 minutes)
• App Installer scripts
• SSH sessions
• cron jobs

Apps and workers share one set of limits; SSH sessions and cron jobs share a second set with the same values. When you first give a customer with running apps a limit, the panel restarts those apps once to move them under it, which takes a few seconds.

What they don't cover yet

PHP websites are not limited. WordPress and other PHP sites run in the server's shared PHP service, outside the customer's limits. Each PHP site is still capped by its own pool settings, which bound how many requests it handles at once, but not its CPU or memory. Covering PHP is planned.

Servers that can't enforce limits

Limits need cgroup v2, which every supported Ubuntu and Debian release uses. Some containers (LXC, OpenVZ) don't give the panel the controls it needs. In that case the Packages page shows a warning that says which part is missing, and the values are saved but not enforced.

Checking it works

As root on the server, systemctl status novapanel-u$(id -u <user>).slice shows a customer's apps and the panel-launched processes with their limits, and systemctl status user-$(id -u <user>).slice shows their SSH sessions and cron jobs.