The agency shares deploy@client.com / Summer2024! with five people. A freelancer leaves — nobody changes the password "so prod won't get blocked." Six months later, audit reveals ghost access and files modified with no identifiable author. A shared password is not team access — it is a time bomb.
SFTP (SSH File Transfer Protocol) encrypts transfers and relies on system or virtual accounts. Best practice: one login per person, minimal permissions, individual revocation — aligned with host/client responsibility.
Recommended model by hosting type
| Level | Setup |
|---|---|
| Shared | Additional SFTP accounts via panel; folder limited to client site |
| VPS | Distinct Linux users; www-data group; no shell if SFTP only |
| Mature | Git + CI deployment (GitHub Actions); SFTP reserved for emergencies |
| Authentication | authorized_keys per user; never a key shared on Slack |
Disable cleartext FTP; force SFTP on SSH port (22 or documented custom port). If the host offers only legacy FTP, change offer or move to VPS.
Permissions, chroot and least privilege
An SFTP user should only see what they must modify:
- Chroot or jailkit: user accesses only
/var/www/client. - Read-only for audit contractor; write for active integrator.
- Never shared root — do not give the host master panel to a freelancer.
- Logs: check SSH
auth.logand correlate with support tickets.
If compromise is suspected, follow abuse reporting procedure and rotate affected keys and secrets.
Revocation and onboarding
Checklist when a contractor leaves:
- Disable SFTP account or remove their public key.
- Change secrets they may have seen (API, database if accessed).
- Review recently modified files (
git logor modification dates). - Update internal documentation of authorized access.
On arrival: individual account, registered key, documented allowed paths — not "the same as everyone."
The peak: shared password is invisible debt
Here is what "one FTP access included" offers do not say the day a freelancer leaves.
Compare multi-account offers and VPS via the directory and comparison tool.
Decide and move forward without blind spots
In one day you can put team access on solid ground:
- Inventory who has access today and immediately revoke any shared generic account.
- Create individual accounts and keys with permissions limited to project folder.
- Move routine deployment to Git and CI if the team allows — SFTP becomes the exception.
- Write contractor onboarding and offboarding procedure, with timelines and owners.
- Test revocation: disable a test account and verify other access still works.
To choose a host allowing multiple accounts or a suitable VPS, browse the directory.
Frequently asked questions
SFTP or FTP for a team?
SFTP only. Cleartext FTP is obsolete and exposes credentials on the network. FTPS is rarely needed if SFTP or Git deployment is available.
How to revoke a freelancer without breaking everything?
With a dedicated account, disable the user or remove their key from authorized_keys. Other team members continue working normally.
Does shared hosting allow multiple SFTP accounts?
Depends on the offer — check number of additional FTP/SFTP accounts before signing. Otherwise, VPS with separate users offers more control.
SSH key or password?
Prefer one SSH key per person protected by passphrase. Strong password per account remains acceptable as last resort — never one login for the whole team.
If your team shares an SFTP password, the question is not "if" you will have an incident — it is "when" you will not know who is responsible.