Docs / SSH & Terminal / SSH Access

SSH & SFTP Access

Panelica 1.0.391 Verified 2026-07-27 SSH & Terminal

The SSH page is where you connect to your account from a real terminal or an SFTP client: it shows your connection details ready to copy, manages the public keys that let you log in without a password, and lets you create additional SSH or SFTP accounts, each locked to its own files and its own share of the machine.

Panel locationTools → SSH Accesshttps://YOUR-SERVER-IP:8443/tools/ssh

SSH Access

SSH Enabledfull shell · /bin/bash

ssh [email protected] -p 22

SSH/SFTP Users Command Permissions SSH Keys Login History Quick Guide

Your connection at a glance

When SSH is enabled for your account, the top of the page shows a green banner with your exact connection command, ssh username@server-ip -p port, ready to copy, plus a details card with the server IP, port, your username, access level, shell and home directory, each copyable. Whether SSH is on is decided by your hosting plan, so if the banner is red, it is your provider who enables it, not a switch on this page. Administrators always have SSH regardless of plan.

Two kinds of access: jailed and full

Additional accounts you create come in two flavors, and the difference is exactly what you would want it to be:

Mode	Shell	What it can do
Jailed (SFTP-only)	none	Transfer files over SFTP, locked inside its home. No terminal, no commands.
Full (SSH + SFTP)	bash	A real shell plus SFTP, still locked to its own files.

Pick Jailed for a designer or a deploy key that only needs to move files, and Full for a developer who needs a command line. Both are confined; the only question is whether a terminal is offered at all.

How a session is put together

Every connection walks the same short path, and each step either narrows what the session can see or caps what it can use:

Session path

1 Connect — ssh or SFTP client reaches the server

↓

2 Access level decides the door — a jailed account goes straight to SFTP inside its jail and stops here; a full account continues to a shell

↓

3 Walls go up — the session is locked into its own view of the filesystem, and with namespace isolation its own process list too. Other customers' files are not hidden; from in here they do not exist

↓

4 Ceilings attach — CPU, memory, swap and process limits from the plan or the account itself are applied to this session before the shell starts

↓

5 The prompt tells the truth — [isolated] or [jailed], and free / top / htop report the account's own resources, not the whole server's

Reading your isolation from the prompt

Every shell session announces what it is. The first thing on the prompt is a label, and it is not decoration — it tells you exactly which walls are around you:

Prompt	Isolation	What it means
`[isolated] alice@server:~$`	Namespace	Own process list and mount table, plus everything below. `ps aux` shows only your own processes.
`[jailed] alice@server:~$`	Chroot jail	Own view of the filesystem. `/root` and other customers' homes are absent, not merely unreadable.
`[restricted] alice@server:~$`	Command allowlist in force	As above, and only the commands an administrator granted are reachable.

Absent beats denied. Inside a jail, cat /etc/shadow answers No such file or directory, not Permission denied. The difference matters: "permission denied" means the file is there and you were turned away, one misconfiguration from being readable. "No such file" means that from where you are standing it does not exist, so there is no permission to get wrong. You can check this yourself in any session.

Behind the scenes: real accounts, real isolation. Unlike FTP (which uses virtual users), an SSH or SFTP account is a genuine Linux user, created with the right group membership and a shell of /bin/false for jailed accounts or /bin/bash for full ones. A jailed account is chrooted by SSH itself with a forced internal-SFTP command: inside, it sees only its own home, and the account list on the server shows nobody but itself. A full account is wrapped so that logging in drops you into an isolated view of the filesystem containing only your own home and a curated set of tools, and your session is placed in your account's cgroup so its CPU and memory are capped. Either way, one account cannot wander into another customer's files.

Resource limits, per account

An SSH account gets its own ceilings, set when you create it and editable afterwards: CPU percentage (100 = one core), memory, swap and a process count. The dialog arrives with the values already filled in, so you can see what the account will actually receive rather than discovering it later.

The process limit is the one that is easy to overlook and hardest to do without: it is what makes a fork bomb survivable. A loop spawning processes forever meets its ceiling and stops, instead of exhausting the kernel's process table and taking every account on the machine with it.

Your limits show up honestly inside the shell. Panelica runs LXCFS, so inside a full account free, top and htop report your account's memory, not the whole server's. This is not cosmetic: software sizes itself from those numbers — the JVM picks a heap, PostgreSQL tuners pick buffers, PHP-FPM calculators pick a worker count — and on a platform that reports the host's figures they configure themselves for a machine many times larger than they are allowed to use, then get killed for exceeding a limit nothing told them about. The core count agrees too: an account allowed 300% is given three cores, and nproc, /proc/cpuinfo and the per-core meters in top and htop all say three.

One number is not yet virtualized: swap. Inside a session free reports no swap even when the account has a swap allowance, because the version of LXCFS shipped by some distributions switches swap reporting off entirely on this kernel layout. The allowance itself is enforced by the kernel and is unaffected — only the reported figure is missing. Distributions carrying LXCFS 6.0 or newer (Debian 13, Ubuntu 26.04, AlmaLinux 10, Rocky 10) report it correctly.

An account created without a panel user — the Independent option in the owner list — has no plan to inherit limits from, so these fields are what constrain it. They are not optional in practice: without them such an account would run with no ceiling at all.

What a 200% / 1 GB account sees

1[|||||||||||||||| 42%]  Tasks: 3 — its own processes, nobody else's
2[||||||          17%]  two meters, because 200% means two cores
Mem[||      38M/1.00G]  the account's gigabyte, not the server's total
Swp[         0K/256M]  its swap allowance, honestly reported
Software sizes itself from these numbers — a JVM picks its heap, PHP-FPM its workers — so reporting the real ceilings is what keeps them from configuring for a machine they are not allowed to use.

Command permissions

The Command Permissions tab narrows what a full-shell account may run. An account with no list is unrestricted, which is what every account is until you narrow it and what they stay after an upgrade — turning this on is always a deliberate act.

Ticked means the account may run it. The editor opens showing the account's real state rather than an empty slate, and saving with everything still ticked means "no restriction" rather than silently pinning the account to today's command list. A small baseline (ls, cat and friends) cannot be removed: a shell without them is not restricted, it is broken.

The list is what the account can actually reach. Commands are only offered if they exist inside that account's jail. A distribution ships different tools in different places — wget is not installed by default on AlmaLinux and Rocky, for instance, while curl is everywhere — and offering a command the account cannot run would produce "command not found" while the panel insisted it was allowed.

Nothing that could be used to leave the jail or change the machine is offered at all: no package managers, no service control, no user management, and nothing that runs with elevated privileges.

Opening a terminal from the panel

Full-shell accounts have a terminal button in the account list. It opens a shell as that account, inside the same isolation the account gets over SSH — same jail, same limits, same prompt label. Copy and paste work through the keyboard, the right-click menu, or middle click.

SFTP-only accounts show the button disabled: they have no shell to open, and offering one would promise access the plan withholds. For a terminal as the server itself rather than as an account, see the web terminal.

Deleting an account: the files are a separate decision

Removing an account asks what should happen to its files, and keeps them unless you say otherwise. The account, its SSH access and its isolation always go; the directory is yours to decide about.

Deleting files cannot be undone, so it is never the default. An account may be pointed at a directory that was already there — a live site, a shared upload folder — and removing that would take content the account merely had access to. A directory shared with other accounts is refused outright, whatever you tick: consent covers your own files, never somebody else's.

Public keys, the passwordless way

The SSH Keys tab manages the public keys that authorize logins. You generate a key pair on your own computer (ssh-keygen -t ed25519) and paste the public half here; the panel validates it, shows its fingerprint, and writes it into your account's authorized_keys. The panel never generates or holds your private key, that stays on your machine, which is the whole point of key authentication. Remove a key and its authorization is revoked. When creating an SFTP/SSH account you can require key authentication, password, or both.

Why keys beat passwords: a strong SSH key cannot be guessed or brute-forced the way a password can, and it never travels to the server. Generate one, add it here, and if your provider permits it, ask them to turn off password authentication entirely for the hardest-to-crack setup.

The quick guide, and login history

The Quick Guide tab is a copy-paste walkthrough: generate a key on Linux, macOS or Windows (PowerShell or PuTTY), print your public key, connect, and set up an ~/.ssh/config entry so you can just type ssh myserver. The Login History tab shows recent SSH logins (from the server's own login records), so you can see when and from where your account was accessed.

For ROOT: the SSHD configuration tab

ROOT gets an extra tab that edits the server's actual SSH daemon settings, safely: root-login policy, password vs key authentication, the SSH port, max auth tries, TCP and X11 forwarding and more. Every change is validated with sshd -t and backed up first, and a bad config is rolled back automatically rather than locking you out, with extra confirmation prompts on the dangerous toggles (disabling password auth, changing the port, permitting empty passwords).

Changing the SSH port or auth policy is a lock-yourself-out risk. The panel validates and keeps timestamped backups precisely because this is the setting that, done wrong, ends a remote session for good. Change the port with a second way into the server available, and never disable password auth until a working key login is confirmed.

What has to be switched on

Three things decide how much isolation an account actually gets, and they sit in different places:

Setting	Where	Effect when off
`ssh_access` licence feature	Your Panelica licence	No SSH accounts can be created at all.
SSH access in the plan	Users & Plans → the plan → SSH access level	The plan's users get no SSH; account creation is refused.
Resource isolation	Panel Settings → Resource Isolation	No CPU, memory or process ceilings are applied.
Namespace isolation	Panel Settings → Resource Isolation	Accounts fall back to a chroot jail; the prompt reads `[jailed]` instead of `[isolated]`.

Both isolation switches are on by default on a new installation, and changing either takes effect immediately — no restart. Turning namespace isolation off tears down the namespaces and leaves the jails; turning it back on rebuilds them. No customer data is touched either way.

The panel records what an account actually has, not what was asked for. If a namespace cannot be built on a particular system, the account keeps its jail and the panel says chroot — it will not claim isolation the account does not have. The prompt label and the account list always agree with reality, which is what makes them worth reading.

Access

Behind the ssh_access license feature, scoped by the roles and permissions chain: you manage your own keys and sub-accounts, resellers their customers', ROOT everything. The main account's SSH availability is a plan setting (administrators are always enabled), account creation is permission-gated per role, and the SSHD configuration tab is ROOT-only. Suspending an account blocks its login at the system level, key or password alike.

Panelica Documentation · Written and verified against the live panel. · Last verified 2026-07-27 on Panelica 1.0.391