Sharing a No-KYC VPS With a Team: Access, Keys and Who Controls the Account

A Linux VPS handles multiple people without any trouble — that part is solved by giving each person their own user account and SSH key. The fragile part of sharing a no-KYC VPS is the billing account, because an anonymous account has no email address to attach a second owner to, no password reset link, and usually just one recovery key. So before you invite anyone onto the server, decide two separate things: who controls the account, and who gets access to the machine.

Those are not the same question, and conflating them is how small teams lose servers.

The two layers you're actually sharing

Layer 1 — the provider account. This is where reinstalls, reboots, plan upgrades, and renewals happen. On IronBalkans, an account is a random account ID plus a recovery key, with no email, name, or phone attached. That's excellent for privacy and unforgiving for teams: whoever holds those two strings can wipe the server, and there is no "forgot password" path if nobody holds them. If you hand the recovery key to a teammate, you have not created a sub-user — you have created a second full owner.

Layer 2 — the server itself. This is standard Linux multi-user administration: per-person accounts, individual SSH public keys, sudo rules, and logs. It's granular, revocable, and auditable. Almost everything you want from "team access" belongs here.

The practical rule: keep Layer 1 with one custodian, and do all team access on Layer 2.

How to set up per-person server access

Don't share a root password or a single SSH key between people. A shared key means you can't tell who did what, and you can't remove one person without rotating the key for everyone.

Create a user per person and drop their own public key into their own authorized_keys:

adduser --disabled-password maria
mkdir -p /home/maria/.ssh
# paste maria's public key only
nano /home/maria/.ssh/authorized_keys
chmod 700 /home/maria/.ssh
chmod 600 /home/maria/.ssh/authorized_keys
chown -R maria:maria /home/maria/.ssh
usermod -aG sudo maria        # Debian/Ubuntu; use 'wheel' on AlmaLinux

Then make sure nobody can bypass that structure. In /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups sudo sftpusers

AllowGroups is the piece people forget: it means a leftover system account with a stray key can't log in at all. Test the config with sshd -t and keep a second session open while you reload, so a typo doesn't lock the whole team out. The full reasoning behind each of these settings — including what genuinely reduces risk versus what's cargo cult — is covered in our guide to SSH hardening on a VPS.

Give out the smallest useful privilege

Not everyone needs root. A developer who only deploys a web app needs write access to the app directory and permission to restart one service — not full sudo. A narrow sudoers rule covers that:

maria ALL=(root) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

Place rules in /etc/sudoers.d/myapp and validate with visudo -c. This isn't paranoia about your colleagues; it's damage control for the day one of their laptops gets malware. A compromised key that can restart one service is an incident. A compromised key with full root is a rebuild.

Keep an access inventory

Write down, somewhere outside the server, who holds a key, what group they're in, and which sudo rules apply to them. On a no-KYC VPS there's no provider-side identity record to reconstruct this from later. A five-line text file in your shared password manager is enough — and it's what makes offboarding a two-minute job instead of a guessing game.

Who controls the account — and the recovery key problem

This is the real decision. With no email on file, account recovery depends entirely on the recovery key you were given at signup. We've covered how that works in detail in no-email VPS signup and recovery keys, but the team-specific implications are worth spelling out:

• One custodian creates the account and stores the account ID and recovery key in an encrypted vault, not in a group chat, not in a shared Google Doc, not in a screenshot.
• At least one backup holder should have a copy, stored the same way. A single custodian is a single point of failure — if they lose their laptop or simply stop answering, the team loses control of billing and reinstalls even if everyone still has SSH access.
• Everyone with the recovery key is an owner. There's no read-only role to hand out. If you don't want someone able to reinstall the OS, don't give them the key; give them SSH instead.

Small teams often handle this by putting the credentials in a self-hosted Vaultwarden instance that two people can unlock, with an offline paper copy stored separately by one of them. It's low-tech and it works.

If identity exposure is the reason you're on an anonymous host in the first place, this structure also matters because no teammate has to put their name, email, or card on anything: IronBalkans accounts require no email, name, phone, or ID, and billing is paid in Monero, Bitcoin, or Litecoin, so there's nothing in the account that identifies any member of the group. Pricing starts at €4.99/mo with deployment in under 60 seconds once payment confirms.

Decide who pays, before renewal day

Crypto billing has no card on file, which means no silent auto-charge — and no silent rescue either. Someone has to actually send the payment each cycle. Assign that to the custodian, not to "whoever remembers," and put a calendar reminder a few days before the due date. The mechanics of renewals, exchange-rate timing, and grace periods are explained in our piece on crypto VPS renewals with no card on file.

Accountability without identity

On a shared server, your audit trail is whatever your logs capture: journalctl -u ssh for logins, /var/log/auth.log or journalctl _COMM=sudo for privilege escalation, and your app's own logs. Because each person has their own account and key, those logs are actually meaningful — "maria ran systemctl restart" tells you something; "root logged in" tells you nothing.

There's a tension here worth naming. Many privacy-focused setups aggressively trim logs, and if you've followed our VPS log minimization approach, you may have shortened journald retention. For a multi-person server, keep enough authentication history to investigate an incident — a couple of weeks of auth logs is a reasonable compromise — and trim the high-volume, personal-data-heavy stuff (web access logs) instead.

When you should use two servers instead of one

Sharing a server is fine when everyone is working on the same project and trusts each other with the same data. It's a bad idea when:

• One person's workload is public-facing and another's is sensitive. A compromise of the public service exposes everything on the box.
• The projects belong to different clients or different legal owners.
• One member wants the server as a VPN exit while another runs a website on it — different risk profiles, shared IP reputation.

At €4.99/mo for an entry plan, a second VPS is usually cheaper than the blast radius of a bad separation decision. We go through the specific trade-offs in one VPS or two.

Offboarding: the five-minute checklist

When someone leaves the project, do all of this, not just the first item:

1. Remove their public key, or userdel -r the account if their files are backed up.
2. Rotate any shared secrets they saw: database passwords, API tokens, WireGuard peer keys, app admin logins.
3. Remove their WireGuard peer entry and reload the interface.
4. If they ever held the account ID and recovery key, you cannot "revoke" that — the only real fix is a new account, and in practice migrating to a fresh server. This is exactly why you restrict Layer 1 to people who will still be around.
5. Check for leftovers: cron jobs, systemd units, authorized_keys files under other users, and ~/.ssh/authorized_keys on backup targets.

Common mistakes

• Sharing one root login. No attribution, no selective revocation, and every exit becomes a full credential rotation.
• Posting the recovery key in a group chat. Chat history outlives team membership. Treat it like a seed phrase.
• Only one person knows the account ID. If they vanish, the team keeps SSH but loses reinstalls, upgrades, and renewals.
• Copying one private key to several machines. A key is a person. Three laptops with the same key is one identity with three attack surfaces.
• Forgetting the backup target. Ex-teammates frequently retain access to the off-site backup repo long after the server key is gone.

FAQ

Can I give someone server access without giving them billing access? Yes — that's the whole point of the two-layer split. SSH access lives on the server and is fully under your control; account access lives with whoever holds the account ID and recovery key.

Does the host know how many people use the server? No. From the provider's side there's one account and one VPS. Who logs in over SSH is your business, and no-KYC signup means none of your team members are identified anywhere in the billing data.

What if a teammate gets locked out? Any remaining sudo user can re-add their key over SSH. That's another argument for having at least two people with sudo — otherwise a single lost key means falling back to console or a rebuild.

Is a separate user per person really necessary for just two people? Yes, and it costs about three minutes. Two people with shared root cannot answer "who deleted this?" — and when one of them leaves, you're rotating everything instead of deleting one line.

Get started

A multi-person setup works best when the boundaries are drawn before anyone logs in: one account custodian with a securely stored recovery key, one Linux user and key per person, narrow sudo rules, and an offboarding checklist you actually follow. If you need a server to build that on, you can deploy a no-KYC VPS in Romania with no email or ID and pay in Monero,