PanelicaDocs
panelica.com
Docs / SSH & Terminal / SSH Access

SSH & SFTP Access

Panelica 1.0.375 Verified 2026-07-24 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.

Panel locationTools → SSH Accesshttps://YOUR-SERVER-IP:8443/tools/ssh
 SSH Access
SSH Enabledfull shell · /bin/bash
SSH Keys Login History Quick Guide SSH/SFTP Users

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.

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, through a namespace and a chroot, into an isolated view of the filesystem containing only your own home and a curated set of tools (bash, ls, nano, vim, grep, htop, ping and friends), 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.
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, and your CPU and memory are genuinely capped by your cgroup (a runaway process is throttled and cannot starve the machine). The one figure that still reflects the host is the CPU core count from nproc (it comes from a kernel call rather than /proc); your actual CPU share is enforced regardless of what that number says.

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.

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-24 on Panelica 1.0.375