Share SFTP Access Securely with a Team

Sending an SFTP password in Slack solves access for a minute and creates an ownership problem for months. Nobody knows who still has it, whether it was copied into a ticket, or what to rotate when a contractor leaves. Exported client profiles and shared spreadsheets create the same problem in a different format.

Secure sharing begins on the server: individual identities, limited permissions and keys that can be revoked independently. A team vault then solves the distribution and organisation layer without pretending that one shared password is ideal.

Compare common ways to distribute SFTP access

The server should know who each person is

Whenever possible, create one SSH/SFTP account or authorised key per person or automation identity. This supports attribution and avoids breaking every user when one key is removed. Limit filesystem access to the directories needed for the role.

Use a bastion, certificate authority or privileged-access system when the infrastructure warrants it. A desktop vault cannot add server-side audit events that the SSH server never records.

Legacy shared hosting may expose only one FTP or SFTP credential. In that case, distribution still needs encryption, named membership and a documented rotation event after offboarding.

How Naucturne’s team vault works

Naucturne encrypts sensitive credential fields on the user’s machine before synchronisation. The personal vault key is derived from a master password with PBKDF2-SHA512 and used with AES-256-GCM. The master password and decryption key are not sent to the service.

For a team, a separate team key is sealed individually for authorised members with RSA-OAEP. Supabase stores encrypted credential content and the metadata needed for accounts and team membership. An authorised member’s device obtains and decrypts the team key locally.

This architecture limits what a database leak reveals. Site names, protocols, hosts, ports, usernames and membership data remain metadata, while passwords, private keys, passphrases and database profiles are ciphertext. It does not protect an unlocked, compromised endpoint where credentials are legitimately decrypted for use.

Share capability, not blanket access

Naucturne teams use owner, admin and member roles. Permissions can be adjusted member by member for:

• file transfer and remote files;
• SSH terminal access;
• MySQL and MariaDB access;
• DNS management.

An editor who deploys static assets does not automatically need database or DNS access. A DNS specialist does not need an SSH shell. Product permissions should mirror server-side least privilege instead of replacing it.

A safer onboarding workflow

1. Create the person’s account

   Invite the teammate by email so access is attached to a named Naucturne identity, not a forwarded vault export.

2. Grant the smallest role

   Select only the files, terminal, database and DNS capabilities required for the assignment.

3. Share the relevant sites

   Keep customer and environment labels explicit. Separate production, staging and personal connections.

4. Verify the first connection

   Confirm the SSH host-key fingerprint through a trusted channel and check the server-side account’s permissions.

5. Review after the task

   Remove temporary access, inspect team membership and rotate any legacy shared secret that may have been exposed.

The same team inventory then opens Naucturne’s dual-pane SFTP workflow, terminal, databases and supported DNS providers without emailing a new connection bundle for each utility.

Offboarding is a process, not one button

Removing a member from the team prevents future authorised access to updated team data. It cannot erase a password, private key or file that the person already copied while authorised.

A complete offboarding checklist should:

1. remove the member from the Naucturne team;
2. disable their individual server accounts and SSH keys;
3. rotate unavoidable shared passwords;
4. review database, DNS, email and provider access;
5. remove local automation tokens and active sessions;
6. document who owns the replacement access.

This distinction matters for every vault product. Cryptography controls distribution; it cannot reverse prior disclosure.

Real-time context reduces a different team risk

Credential sharing answers “who can connect?” Collaboration must also answer “who is changing this server now?” Naucturne provides presence and activity context around shared work and protects sync uploads when the remote content changed since download.

Read how remote collaboration avoids overwrites for the conflict model. Access control and overwrite protection solve different layers of the same team workflow.

When to use a different system

Choose a dedicated enterprise secrets or privileged-access platform when you require short-lived credentials, approval workflows, mandatory session recording, automated rotation or regulatory reporting. Use infrastructure-as-code for machine-managed deployments rather than opening production access to every developer.

Naucturne is positioned as a server-operations workspace for agencies and development teams. Its encrypted vault reduces credential sprawl across file, terminal, database and DNS tools; it does not make server-side identity optional.

Product references

• Naucturne team roles and permissions
• Encryption and threat model
• SFTP client comparison
• One workspace for files, database and DNS

The objective is simple: a new teammate should receive exactly the server context needed for the work, while a departing teammate should trigger a clear and complete revocation path.