Shell access for a website
A website’s own account can be given a shell on the server. The jailed one sees that website, the system programs it needs, and nothing else on the machine, which is what makes it safe to hand to a customer and what an editor working over SSH needs.
Step 1
Choose what the account may do.
Open the website, then Access, then Website account. Only an administrator can change this: what it hands out is a login on your server rather than a setting inside somebody’s website, so it is not something a customer can switch on for themselves and not something an integration key can grant.
| Setting | What the account gets | Who it is for |
|---|---|---|
| No shell | File transfer at most. This is how every website starts. | Everybody, until you decide otherwise. |
| Jailed shell | A shell whose whole filesystem is that website: its files, and the system programs it needs to work on them. | A customer, or a developer working on one site. |
| Normal shell | A shell on the server itself, confined to nothing. | Somebody you trust with the machine, not with one website on it. |
The account needs a password or an SSH key before a shell can be turned on, because a login nobody can use is a control that looks on and does nothing.
Step 2
Add a key, which is what an editor signs in with.
Under SSH keys on the same page, paste the public key: the short file ending in .pub, never the private one. An editor reconnects constantly and a key is what stops it asking for a password every time. A key works for file transfer too, and it is the only way in if you have turned password sign-in off for website accounts.
# on your own machine, if you have no key yet ssh-keygen -t ed25519 cat ~/.ssh/id_ed25519.pub # paste that one line into the panel
The panel keeps the keys, so they are in its own backup and a restore of the website’s files cannot quietly bring an old one back. A key the account holder puts in their own .ssh/authorized_keys works as well, and is theirs rather than yours.
Step 3
Connect.
The account name, the server’s address and the port are all on the same page. The port is read from the machine rather than assumed, so if your SSH has been moved off 22 the page says where it answers.
ssh -p 22 websiteaccount@server.example.com # then, inside cd public_html php -v composer install
For an editor, use its own remote SSH support with the same account, address and port. It installs a small server of its own into ~/.vscode-server the first time it connects, and that directory is created for it in advance.
Inside the jail
What is there, and what is deliberately not.
A jailed shell is not a trimmed-down account on the server. Its filesystem root is a directory built out of the host’s own files, so the tools are the ones the server has and a security update reaches them the moment it lands.
| What | In a jailed shell |
|---|---|
| The website’s files | Where they always were: public_html, private, app, logs. |
| Command lines | php with the extensions that website has, composer, git, mysql, curl, tar and the rest of the system’s own programs. |
| A temporary directory | Its own, inside its own home, so what a build writes there counts against that website’s storage. |
| Other websites | Not present. One home directory exists inside the jail and it is that website’s. |
| The server’s own files | Not present. No configuration, no panel database, no logs, no certificates, no other account’s anything. |
| Other accounts’ processes | Not visible. The process list holds that website’s own and nothing else. |
| Becoming root | Not possible from inside. The system programs are mounted so that none of them can change who is running it, so sudo and its relatives are present and all fail. |
Two surprises
The first folder, and editing as root.
The top of the home directory will not let you write. Create your files one level down, in public_html or private or app. That is the same rule file transfer has and it is there for a reason: a website that could write the top of its own home could replace its log directory with a link to somewhere else, and the web server writes in there as root. The directories a shell and an editor actually need are created for you, so ~/.ssh, ~/.cache, ~/.config, ~/.npm and ~/.vscode-server are already there and are yours to write.
Do not edit a website’s files over SSH as root or as your own administrator account. The files end up owned by the wrong account, and that website’s next backup refuses, saying it found a file it does not recognise. Work as the website’s own account, or put the ownership back with the file manager’s Permissions action.
A normal shell
What you are agreeing to.
A normal shell is the server. It is confined to nothing, it can read every file on the machine that any account can read, and that includes other websites’ published files. It is the right choice for your own developer and the wrong one for a customer. Turning it back to No shell takes the login away at once.