Extra accounts for your developers

Your own oN.ftp login can reach every site on your account. That's exactly right for you — and exactly wrong for an outside developer or agency you've hired to work on one site. Handing them your main login would let them see (and change) everything else too, and you'd have to change your own password when the job ends.

There's a better way built in: from the control panel, you can have the system create a separate, limited login — its own SSH, SFTP and FTPS access, with the same fenced-in shell you have — that reaches only the sites you choose. You stay in control the whole time: you hand over the password yourself, you can force a new password at any moment, and you can switch the whole login off from the panel when the work is done.

How it works: Clients and owners

The control panel has a concept called a Client — a way of saying "this site belongs to this person or company". Extra accounts hang off Clients:

1. Create a Client in your control panel — give it the developer's or agency's name.
2. Edit the site you want them to work on, and set that Client as the site's owner (the Client field on the site's form).
3. Wait a few minutes. The system notices the new arrangement on its next sweep and builds the login automatically — typically within about 3 minutes.

That's the whole setup. The new login's username is your account name plus the Client's name in lowercase letters and numbers — a Client called Acme Corp on account o1 becomes o1.acmecorp. You don't have to work the name out, though: it appears as a file in your account, which is also where the password is (next section).

A few useful rules fall out of this design:

• A site has one owner. You can't attach two Clients (and so two extra accounts) to the same site.
• A Client covers all its sites with one login. Make the same Client the owner of three sites, and its one account reaches all three.
• Separate people should get separate Clients. Everyone using a Client's login is indistinguishable from each other. If you want two developers to have their own credentials — or to be able to cut one off without the other — create a Client for each and split the sites between them.

When the developer logs in, they land in a home directory of their own with a sites folder listing one entry per site they can reach. They get the same limited shell you have — Drush, Composer, Git, the file tools — but fenced to those sites and their files. They can't see your home directory, your backups, your other sites, or anything belonging to another Client.

Where the password is — and how to send it

The system generates a strong password for the new login and puts it inside your own account, in a folder called users in your home directory. Connect as usual (shell or SFTP) and look at:

~/users/

You'll find one file per extra account. The file's name is the developer's username; the file's content is their password. For the example above that's a file named o1.acmecorp containing a single long password line.

The file only appears once the Client actually owns at least one site — a Client that owns nothing, or whose only site has been deleted, gets no login. (Disabling a site is not enough to switch its owner's login off — see removing access, below.) And nothing is sent anywhere automatically: the system writes the file and stops there. You read it and pass the details to your developer however you prefer — ideally somewhere more private than plain email.

Your developer then connects with:

Everything on shell and SFTP access applies to them too: the same programs, the same limited-shell rules, and the same trick of adding an SSH key (to their account's ~/.ssh/authorized_keys) so they stop typing the password.

If they prefer FTPS. The server also offers FTPS — encrypted FTP — for these accounts. In the file-transfer program choose FTP with explicit TLS (some programs call it FTPES or "Require explicit FTP over TLS") on port 21, with the same username and password. Plain unencrypted FTP is refused, so if a connection fails, check the TLS setting first. SFTP on port 22 is still the simpler choice when the developer's tools support it.

Changing the password

To force a fresh password at any time — say, at the end of a contractor's engagement — delete the password file from your ~/users/ folder:

rm ~/users/o1.acmecorp

Within about 3 minutes the system rebuilds the account with a brand-new password, and the file reappears with the new content. Read it and send it on, as before.

Rotation is a rebuild. Deleting the file makes the system remove the extra account completely and create it afresh — that's what guarantees the old password is dead. The developer's own home directory goes with it, including any SSH key they'd added, so they'll need to re-add their key after a rotation. Your sites are never touched: they live in your account, and the extra login only reaches them through links.

The 90-day password expiry you know from your own login applies to extra accounts as well. A key keeps the developer's daily logins working across it, and deleting the password file is the self-service way to issue them a current password whenever one is needed.

Removing access

When the engagement ends, go back to the control panel and delete the Client (or simply take its sites away — change each site's owner, or leave the Client owning nothing). On the next sweep, within about 3 minutes, the extra login is removed completely — SSH, SFTP and FTPS all stop working at once, and its password file disappears from your ~/users/ folder.

One thing that does not cut access: disabling a site. A disabled site still exists and still counts as owned, so its owner's login stays active. To actually end someone's access, delete the Client or change the site's owner, as above.

There's nothing else to clean up. Anything the developer did inside your sites stays exactly where it is — the code and files belong to your account, not to the extra login — and your own credentials were never shared, so there's nothing to change on your side.

Where to go next

• Shell and SFTP access — what the limited shell allows, connecting with SFTP, and setting up an SSH key; it all applies to extra accounts too.
• When you can't connect — if the new login is refused, the same two culprits apply.
• Managing your sites — the panel-side view of your sites, where the owner is set.