The safe pattern is simple: create one named, non-root Unix account for each developer, install that person’s own SSH public key, and grant only the groups or commands required for the work. Never copy your private key, share a root password, or let several people use one account.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Before changing SSH, keep an administrator session open and verify an emergency provider console or recovery path. Then test the developer’s login, privilege boundaries, logging and revocation process while you can still repair a mistake.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
Why a separate account is safer than sharing yours
A VPS login is both a credential and an audit identity. If three people use your account, the server records the same Unix username for all of them. You cannot reliably tell who changed a configuration file, restarted a game service or deleted a log. A shared private key also has no clean revocation point: replacing it means coordinating a new key with everyone who used the old one.
With one account per person, each developer has an independent public key in that account’s authorized_keys file. You can remove one key without changing anyone else’s access, and authentication and sudo records retain the person’s username. The account can be disabled, removed from a group or stripped of a sudo rule without touching your administrator account.
#1 Best Overall
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Least privilege is the governing rule. A developer who only deploys files may need write access to one application directory and permission to restart one service. That does not justify a root shell, access to other customers’ data or unrestricted package-management rights. Ordinary users should have no sudo access unless a specific administrative action requires it.
Choose the access design before you create accounts
Decide what the developer must do, not what would be convenient to grant. Write down the application directories, services, ports, databases and maintenance commands involved. Then select the narrowest design that supports the job.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors| Design | Identity separation | Privilege scope | Authentication | Revocation effort | When it fits |
|---|---|---|---|---|---|
| Shared root or shared administrator login | None | Unlimited | One password or key used by several people | High; changing it affects everyone | Avoid. It destroys attribution and magnifies the impact of a leaked credential. |
| Named non-root account with SSH key | One Unix account per person | No sudo; directory or group permissions only | Individual public key | Low; remove one key or account | Deployments, content updates and routine application work. |
| Named account plus command-limited sudo | One Unix account per person | Only listed commands, ideally through a root-owned wrapper | Individual key, optionally a second factor | Low; remove the rule and key | Restarting a service, reading protected logs or running a defined migration. |
| SSH reachable only through a VPN or allowlisted network | Depends on the Unix accounts | Any of the scopes above | Key, with optional FIDO2 or TOTP | Low for accounts; network membership must also be removed | Teams with a stable office, VPN or bastion network. |
| Central identity provider with short-lived credentials | Usually per-person identities | Policy-based | Provider-controlled MFA and keys | Centralized; disable the identity once | Larger teams managing many servers. Confirm how the provider maps identities to Unix accounts. |
The rest of this guide assumes a Linux VPS using OpenSSH and an Ubuntu or Debian-style layout. Package names, service names and firewall commands differ on other distributions, so check that system’s documentation before applying them.
Prepare a recovery path before touching SSH
An SSH configuration error can lock out every remote administrator. Do not close your current administrative session until a second, independently tested session works. In addition, open your hosting provider’s serial console, web console or rescue environment and confirm that you know how to use it. Keep a backup administrator key offline.
- Record the current SSH configuration and the port on which
sshdlistens. - Confirm that at least one administrator can log in with a key before password authentication is disabled.
- Have console access available in case a syntax error prevents
sshdfrom restarting. - Schedule a maintenance window if a firewall or network policy change could interrupt deployments.
Validate a proposed configuration before reloading it:
sudo sshd -t
A successful command produces no output and an exit status of zero. If it reports an error, fix the file before restarting or reloading the service.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 1: Create a named account and the minimum groups
Use a unique, human-readable username such as dev-alice. Do not use a generic developer account for several contractors. The following example creates a login without a usable password and creates a group for files that the deployment process must modify.
sudo addgroup --system game-deploy
sudo adduser --disabled-password --gecos "" dev-alice
sudo usermod -aG game-deploy dev-alice
sudo usermod -aG sshlogin dev-alice
Create sshlogin first if it does not already exist:
sudo addgroup --system sshlogin
Add only the groups required by the application. Membership in broad groups such as adm, docker or a host-management group can confer more power than it appears to: on many systems, access to a container engine or protected logs can be equivalent to root. Review existing group privileges before adding a user.
Rank #2
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Give the deployment group ownership of a dedicated path rather than an entire home directory or filesystem. For example:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →sudo install -d -o root -g game-deploy -m 2770 /srv/mygame/releases
sudo install -d -o root -g game-deploy -m 2770 /srv/mygame/shared
The set-group-ID bit (2 in 2770) keeps new files in the application group. Make sure the service itself can read the release path, and avoid granting write access to directories containing system binaries or SSH configuration.
Step 2: Have the developer generate a personal SSH key
The developer should create the key pair on their own computer. For a new key, Ed25519 is the preferred default on current OpenSSH installations. The private key stays on that device and should be protected with a strong passphrase; only the public file ending in .pub is sent to you.
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519
The command asks for a passphrase. The -a 100 option increases the passphrase-hardening work factor on OpenSSH versions that support it. If an organization requires a hardware-backed key or a different algorithm, follow that policy instead. Never request the private key, a copy of the developer’s password or an unencrypted archive of their home directory.
Ask the developer to send the complete one-line public key and, if your process records it, its fingerprint:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchssh-keygen -lf ~/.ssh/id_ed25519.pub
Verify the fingerprint through a second channel when the server is sensitive. A public key is not secret, but checking its fingerprint helps prevent installing a key that was altered or copied from the wrong machine.
Step 3: Install the public key with correct ownership and permissions
As an administrator, create the account’s SSH directory and append the supplied public key. The directory must belong to the developer, not to root, and must not be writable by other users.
sudo install -d -o dev-alice -g dev-alice -m 700 /home/dev-alice/.ssh
sudo touch /home/dev-alice/.ssh/authorized_keys
sudo chown dev-alice:dev-alice /home/dev-alice/.ssh/authorized_keys
sudo chmod 600 /home/dev-alice/.ssh/authorized_keys
sudoedit /home/dev-alice/.ssh/authorized_keys
Paste the public key as one uninterrupted line. You may add a descriptive comment at the end, such as the device name and date, but do not wrap the key across lines. If the home directory itself is group- or world-writable, OpenSSH may reject the key depending on its strict-mode checks; correct ownership and permissions before troubleshooting the client.
For a key that should only perform a tightly defined action, OpenSSH supports options before the key, such as from=, command=, no-pty and forwarding restrictions. Use forced commands only when you understand exactly what the deployment tool sends; an incorrect restriction can break a legitimate workflow or create a false sense of security.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Step 4: Test the developer session before changing global settings
Have the developer connect in a new terminal while your administrative session remains open:
ssh -i ~/.ssh/id_ed25519 [email protected]
Replace the hostname with your VPS address and use the actual private-key path on the developer’s computer. Once connected, verify the identity and baseline permissions:
whoami
id
pwd
sudo -n -l
whoami must show dev-alice, not your administrator username. id confirms group membership. If the account is not supposed to use sudo, the final command should report that no permission is available; that is an expected result, not a failure.
Test the real work at its normal scope: clone or upload a release into the permitted directory, read the logs the developer needs, and attempt an operation that should be denied. Record both outcomes. A permission model is not finished until the allowed task works and an obviously excessive task fails.
Step 5: Delegate privileges deliberately
Prefer filesystem and service groups over sudo
If the developer only needs to update application files, use ownership and group permissions. A deployment group can write to a release directory while system configuration remains root-owned. If a service must read secrets, keep those secrets outside the developer-writable path and grant the service account access, not the developer.
Use a root-owned wrapper for a small, repeatable operation
A wrapper script can validate arguments and perform one administrative action. For example, a root-owned /usr/local/sbin/restart-mygame could restart exactly one systemd unit after checking its fixed name. Make the script owned by root and not writable by the developer or any group they control, then grant only that path through sudo.
sudo visudo -f /etc/sudoers.d/dev-alice-mygame
Add a rule like this, using the absolute path to the wrapper:
dev-alice ALL=(root) /usr/local/sbin/restart-mygame
Save the file and let visudo validate its syntax. Test with:
sudo -l -U dev-alice
Command-specific sudo rules must match the command and arguments as intended. Avoid a blanket rule such as dev-alice ALL=(ALL) ALL unless the person is genuinely an administrator and your organization accepts the consequences. Wildcards can be surprisingly broad; a wrapper is often safer than trying to express complex argument validation in sudoers.
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Understand what sudo grants
Some commands can launch an editor, shell or interpreter, turning a seemingly narrow permission into unrestricted root access. Treat package managers, text editors, scripting runtimes, service managers and container tools as privileged interfaces. Review each command’s escape mechanisms before allowing it. Sudo records authorized and unauthorized attempts in the system’s authentication logs by default, which gives you an audit trail when each person has a separate account.
Step 6: Limit which accounts may use SSH
An sshlogin group lets you express a positive list of accounts allowed to connect. In /etc/ssh/sshd_config, add or edit:
AllowGroups sshlogin
Add every required administrator and developer to that group before reloading SSH. Check the effective configuration and syntax:
sudo sshd -t
sudo systemctl reload ssh
On some distributions the service is named sshd rather than ssh. Reloading keeps existing sessions alive while applying the new policy. Open a fresh session for every required account and verify it before closing your original administrator connection.
A firewall or provider network policy can reduce exposure further. For example, a rule allowing TCP port 22 only from an organization’s known range is safer than exposing it to every address:
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
203.0.113.0/24 is a documentation range; replace it with the actual office or VPN range, and do not apply an allowlist that excludes your recovery path. If developers work from changing networks, require a VPN or another controlled entry point instead of constantly opening new public ranges.
Step 7: Harden authentication after key login works
Once every required administrator has successfully tested key authentication and your recovery path is confirmed, disable direct root SSH login:
PermitRootLogin no
Then disable password authentication:
PasswordAuthentication no
Keep public-key authentication enabled:
PubkeyAuthentication yes
Do not blindly disable keyboard-interactive authentication if you use a one-time-password challenge. TOTP deployments commonly use that method; change it only after confirming how your second factor is integrated. Validate and reload the configuration, then test a new connection from a separate terminal. Never make these changes solely from the session you are currently using.
For privileged accounts, add a second factor where practical. Ubuntu documents hardware-backed U2F/FIDO authentication and HOTP/TOTP as additional SSH layers. A FIDO2 security key provides phishing-resistant authentication when the SSH client, server and account policy support it. TOTP is more widely available but depends on protecting the authenticator secret and recovery codes. Apply the second factor to administrators first, and document an emergency replacement process for a lost key or phone.
Best Value
- FIDO2 & Passkey Ready: Business-ready and FIDO2 L1 certified. This key is supported by major management suites and is ideal for both individual and enterprise deployment. Works seamlessly with Gmail, Facebook, GitHub, Dropbox, Coinbase, and more.
- Universal Connectivity (USB-A ): Features a built-in USB-A connector—simply unfold the key and plug it into your compatible PC or laptop for seamless authentication on the go.
- Dedicated Manager App: Use the Thetis Manager App for the initial hardware PIN setup. Setting the PIN on the device first ensures a smooth registration process. Once the PIN is configured, you can begin registering the key across your favorite FIDO2-compatible online services.
- Ultra-Durable & Portable: Featuring a rotating metal cover, this key is water, crush, and tamper-resistant. It fits easily on a keychain and requires no batteries or network connectivity.
- Check FIDO2 compatibility before purchase - Known limitations: ID Austria is not supported (requires FIDO2 Level 2). Windows Hello login only works with Windows Enterprise editions that support Entra ID, and NFC is NOT supported.
Design access around the application, not the whole VPS
Game servers often need a developer to deploy a build, inspect logs, rotate a configuration value or restart one unit. Separate those needs:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Keep source, build artifacts and releases in a dedicated directory with controlled group ownership.
- Run the game service as its own unprivileged service account, not as the developer and not as root.
- Store credentials and tokens in a root-readable or service-account-readable location outside the developer’s writable tree.
- Grant read-only log access where possible; avoid granting broad access to every user’s home directory or database dump.
- Expose only the game ports required by players. SSH access is an administrative channel and should not be confused with the ports used by the game service.
If the developer needs database access, create a database identity with the minimum schema and operation permissions rather than handing over the VPS administrator credential. The same per-person principle applies inside the database: individual identities make revocation and investigation possible.
How to revoke a developer cleanly
Revocation must remove every authentication and authorization path. Locking a Unix password alone is not enough: a user who already has an SSH public key can continue to obtain a shell without entering a password.
- Remove the person’s SSH keys. Inspect
/home/dev-alice/.ssh/authorized_keys, identify the correct fingerprint and delete every key belonging to the developer. Check for additional keys in other accounts, service accounts and deployment users. - Stop new logins immediately if needed. Lock the account and change its shell while you complete the review:
sudo passwd -l dev-alice
sudo usermod -s /usr/sbin/nologin dev-alice
These commands are emergency controls, not substitutes for removing keys. A key can remain usable in another account or through an automation system.
- Remove authorization grants. Delete the user from application and SSH groups, remove their file from
/etc/sudoers.d, and remove any per-key forced-command or source-address entries. - Terminate existing sessions and processes. Review
who,wand the process list. On systems using systemd-logind,sudo loginctl terminate-user dev-aliceends that user’s sessions; otherwise terminate the specific sessions and processes according to your operating procedure. - Revoke non-SSH credentials. Remove deployment tokens, CI secrets, cloud credentials, database users, API keys, VPN membership and provider identity-provider access. Search automation jobs and scheduled tasks for keys that were copied while the developer worked.
- Preserve evidence and decide whether to delete the account. Keep required logs and files for your retention period. When no data must be retained, remove the account and home directory only after confirming that no service or scheduled job depends on them:
sudo userdel -r dev-alice
If the person returns later, create a new account and install a newly generated key. Do not reactivate an old account or reuse an old private key simply because it is convenient.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Audit and maintain the arrangement
Review access on a schedule and after every staffing or contract change. Compare the account list, SSH keys, group memberships and sudoers files with the people who are currently authorized. Fingerprint each key so an unfamiliar line in authorized_keys can be identified quickly.
- Inspect recent SSH authentication events in the system authentication log and review successful and failed attempts.
- Review sudo records for unexpected commands, especially commands that modify users, SSH configuration, firewall rules or service definitions.
- Check for keys in service accounts, root’s SSH directory and deployment agents, not just named human accounts.
- Rotate keys when a device is lost, a private key may have been copied or a contractor’s control of a machine is uncertain.
- Keep a written record of why each group or sudo rule exists and who approved it.
Access reviews are also a chance to remove obsolete accounts and stale keys. A key with no comment, owner or last-review date should be treated as untrusted until someone can identify it.
Troubleshooting common failures
The client says “Permission denied (publickey)”
- Confirm the developer is using the matching private key and the correct username.
- Check that the public key is one line in the intended account’s
authorized_keys. - Verify ownership and modes: the home directory must not be writable by unrelated users,
.sshis normally700, andauthorized_keysis normally600. - Check server authentication logs for the precise rejection reason, such as an invalid group, a refused source address or a key type disabled by policy.
The developer can log in but cannot perform the deployment
Run id in a new session to pick up newly added group membership. Confirm the target directory’s owner, group, mode and any filesystem ACLs. If the deployment requires a service restart, add a narrowly scoped wrapper and sudo rule rather than granting full administrator access.
A sudo rule is broader or narrower than intended
Use sudo -l -U dev-alice to inspect the effective policy. Check the exact command path and arguments, look for wildcards, and test both an allowed invocation and a clearly disallowed one. Run visudo whenever editing sudoers files.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →You are locked out after an SSH change
Keep the original session open whenever testing. If all sessions fail, use the provider’s console or rescue environment to restore a known-good configuration, run sshd -t, and reload SSH. This is why an out-of-band recovery path must be prepared before disabling root or password login.
The key still works after the password was locked
That behavior is expected for an account with public-key authentication. Remove the key from authorized_keys, terminate existing sessions and inspect other accounts and automation systems for copies of the credential.
Quick Recap
A practical hand-off checklist
- One named Unix account exists for each developer; no shared login is used.
- The developer supplied only a public key, and the private key is passphrase-protected on their device.
- The account belongs only to required groups and has no unnecessary sudo access.
- The key file and directory have restrictive ownership and permissions.
- The developer has tested a new session and can perform the required task but not an excessive one.
- SSH access is limited by account group and, where practical, by VPN or source network.
- Root and password SSH login are disabled only after key authentication and recovery access were tested.
- A second factor is enabled for sensitive accounts when the environment supports it.
- You have documented how to remove keys, groups, sudo rules, sessions, tokens and external memberships.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




