iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Give each developer a separate, named Unix account and install only that person’s SSH public key. Keep the account non-root, grant the minimum group or command-specific sudo rights needed for the work, and test a recovery path before changing SSH settings. This preserves attribution in logs, lets you revoke one person without affecting anyone else, and avoids exposing your private key.
What the safe arrangement looks like
A developer should connect with an identity that belongs only to them, not with your owner account, a shared root login, or a copy of your private SSH key. The normal pattern is:
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 →- One named, non-root account per developer.
- One public key (or a small, documented set of keys) in that account’s
~/.ssh/authorized_keys. - Application-specific Unix groups or narrowly written
sudoersrules. - SSH access restricted to approved accounts and, where practical, approved networks or a VPN.
- An emergency provider console, backup administrator key, or other out-of-band recovery method that has been tested before SSH hardening.
Ubuntu’s security guidance describes this as least privilege: ordinary accounts receive only the permissions required for their task, while sudo is reserved for administration that genuinely needs elevation.
Why sharing one login causes trouble
You lose attribution
If several people use the same account, shell history, file ownership, and many audit records identify only that account. A separate Unix username gives you a meaningful trail for deployments, configuration changes, and failed login attempts.
#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
Revocation becomes disruptive
Changing a shared password or replacing a shared key affects every user and every automation job that relies on it. With individual accounts, removing one key and one set of grants leaves the others untouched.
A private key is not a password you can safely copy
Anyone who obtains a private SSH key can authenticate wherever its public half is trusted. Send a developer only their public-key file, normally ending in .pub. The private key stays on the developer’s device, protected by a passphrase, and is never pasted into chat, tickets, scripts, or the server.
Choose the access design before creating accounts
| Design choice | Safer default | When a broader option is justified |
|---|---|---|
| Identity | One account per person | A shared account only for a tightly controlled, non-human automation process; never for a team of people |
| Privilege | No sudo, or a dedicated group for the application |
Command-limited sudo for a documented operational task |
| Authentication | Ed25519 public key | Key plus FIDO2/U2F or TOTP for sensitive administrative access |
| Network exposure | SSH reachable only from a VPN or allowlisted ranges | Public SSH with strong keys and monitoring when a private network is not feasible |
| Revocation | Remove one key and that user’s grants | Central identity management when you have many servers or frequent staff changes |
Write down the exact tasks first: for example, editing files under an application directory, restarting one service, reading logs, or running a deployment command. Those tasks determine group membership and any required elevation.
Prepare a recovery path and an administrator session
Do not begin by editing SSH configuration while your current connection is your only way back in. Confirm that you can reach at least one of the following:
- Your hosting provider’s serial, web, or recovery console.
- A second administrator account with a separately tested key.
- A documented rescue or snapshot procedure that you have actually used or verified.
Keep your current administrative SSH session open while creating and testing the developer account. Open a second terminal for every test; only close the original session after the new login and the recovery route both work.
Record the current state
Before making changes, note the operating-system release, the SSH service name, the current administrator accounts, and any existing firewall or provider network rules. Save a copy of the SSH configuration and the relevant access-control files in a protected location. Do not place private keys in that backup.
Step 1: Create a named account and task-specific group
Use a unique, readable username for each person. On a Debian- or Ubuntu-style system, an administrator can create an account and a group such as appdeploy with:
sudo addgroup appdeploy
sudo adduser --disabled-password --gecos "" maya
sudo usermod --append --groups appdeploy mayaThe --disabled-password option prevents password-based login for this account; SSH public-key authentication remains independent of a Unix password. Choose a username that does not reveal secrets and that will remain understandable in logs.
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.
Do not add the user to broad administrative groups merely for convenience. Membership in a group such as sudo can effectively make the person an administrator. Add only the groups that own the files or sockets the developer must use.
Set application ownership deliberately
If the developer needs to edit a release directory, give the application group access to that directory rather than making the entire filesystem writable. Confirm ownership and mode bits with commands such as:
getent group appdeploy
id maya
namei -l /srv/example-appUse the application’s existing deployment model where possible. Broad recursive ownership changes can break the service account or expose secrets in configuration files.
Step 2: Have the developer generate a key locally
For a new key, Ed25519 is a practical default. The developer runs this on their own workstation, not on the VPS:
ssh-keygen -t ed25519 -C "maya@example"They should choose a strong passphrase and protect the resulting private-key file with the workstation’s normal disk and account security. They send you only the public file, for example id_ed25519.pub. You can ask them to confirm its fingerprint out of band so a mistyped or substituted key is caught before installation.
If an organization already requires a different key type or a hardware-backed credential, follow that policy. Never ask the developer to send the private half “temporarily,” and never use your own private key in their account.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Step 3: Install the public key with restrictive permissions
As an administrator, create the account’s SSH directory and set its owner and modes before adding the key:
sudo install -d -m 700 -o maya -g maya /home/maya/.ssh
sudo install -m 600 -o maya -g maya /tmp/maya_id_ed25519.pub /home/maya/.ssh/authorized_keysThe source path above is an example. Transfer the public file through a channel you trust, verify that it contains one expected key line, and remove the temporary copy afterward. If you append instead of replacing an existing file, inspect every line so an old or unknown key is not silently retained:
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
sudo sh -c 'cat /tmp/maya_id_ed25519.pub >> /home/maya/.ssh/authorized_keys'
sudo chown maya:maya /home/maya/.ssh/authorized_keys
sudo chmod 600 /home/maya/.ssh/authorized_keysCheck the directory and file as the SSH daemon will see them:
sudo ls -ld /home/maya /home/maya/.ssh
sudo ls -l /home/maya/.ssh/authorized_keysHome directories and every parent directory must not be writable by unrelated users. An incorrect owner or mode is a common reason for “Permission denied (publickey).”
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 matchStep 4: Test the new login before touching hardening settings
From the developer’s workstation, start a new session using the matching private key:
ssh -i ~/.ssh/id_ed25519 maya@server.exampleOnce connected, verify identity and effective permissions:
whoami
id
pwd
sudo -lThe expected result is the named account, membership only in the groups you intended, and either no sudo privileges or a short, recognizable command list. Test the actual work in a non-production directory or staging service first. Keep your original administrator session open until you have completed these checks.
Step 5: Grant only the privileges the job requires
Prefer group permissions for application work
For editing, deploying, or reading logs, a dedicated group is usually easier to understand than a long list of elevated commands. Make the application files group-owned, set an appropriate group-write policy, and ensure that secrets remain readable only by the service account or administrators. After changing group membership, the developer must start a new login session for the new group list to apply.
Recommended Free Tools
Use command-limited sudo when elevation is unavoidable
If the developer must restart one service, create a narrowly scoped rule with visudo, which validates syntax before saving. A rule might allow only a specific service action:
sudo visudo -f /etc/sudoers.d/maya-appmaya ALL=(root) /usr/bin/systemctl restart example-app.serviceUse the exact executable path on your system and include only the arguments you have evaluated. Avoid a blanket rule such as ALL=(ALL) ALL unless the person is intentionally an administrator. Remember that many commands can invoke shells, edit arbitrary files, or load plugins; command names alone do not always make a rule harmless.
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.
Sudo authorization and unauthorized attempts are logged by default, giving you an additional audit trail. Review those logs as part of normal operations rather than assuming that a grant will be noticed automatically.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 6: Limit which accounts may use SSH
Create a group for people allowed to log in over SSH and add only approved accounts:
sudo addgroup sshlogin
sudo usermod --append --groups sshlogin mayaIn the SSH server configuration, an AllowGroups sshlogin directive limits SSH authentication to members of that group. Check the complete configuration, including included files, before relying on it. A typo or a missing administrator account can lock you out.
Network controls add another layer. Restrict port 22 at the host firewall, cloud firewall, or provider network policy to a corporate VPN or known source ranges when possible. Source allowlisting is not a replacement for keys and least privilege: addresses can change and approved networks can be compromised.
Step 7: Harden SSH only after every required key works
After you have tested each administrator’s key in a fresh session and confirmed recovery access, review the SSH daemon settings. Common hardening changes include:
- Disable direct root login with
PermitRootLogin no. - Disable password authentication with
PasswordAuthentication noafter key access is confirmed. - Keep public-key authentication enabled.
- Restrict login with
AllowGroupsor an equivalent account policy.
Validate the configuration before restarting the service:
sudo sshd -t
sudo systemctl reload sshUse the service name used by your distribution if it differs. A reload normally preserves existing sessions while applying the new configuration; still keep the original administrator connection until a new login succeeds. If validation fails, do not restart the daemon. Correct the reported line or use the provider console to restore the last known-good configuration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 8: Add a second factor for sensitive access
Public keys protect against password guessing, but a stolen private key is still a credential. For privileged accounts, consider a FIDO2/U2F hardware security key or a time-based or HMAC-based one-time password (TOTP or HOTP) as an additional SSH authentication layer. Ubuntu’s OpenSSH documentation describes both hardware-backed and one-time-password approaches.
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.
Enroll at least one backup factor and document recovery before enforcing the second factor. A policy that depends on one lost device can lock out the only administrator just as surely as a bad SSH configuration.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsHow to revoke a developer safely
Locking a Unix password alone is not enough. Ubuntu user-management guidance explicitly warns that a user who already has an SSH public key can continue to log in remotely without a password. Use this sequence:
- Identify every credential. Find the user’s entries in
authorized_keys, including keys in nonstandard locations, and check deployment keys, automation tokens, API credentials, and external identity-provider memberships. - Remove the SSH key. Delete the specific line from
/home/maya/.ssh/authorized_keysor remove the file when no approved key remains. Preserve a dated administrative record of what was removed. - Remove grants. Take the account out of application and SSH-allow groups, delete its files under
/etc/sudoers.d, and remove any firewall or VPN allowlisting tied to it. - Terminate current access. List the user’s processes and sessions, then terminate them according to your operating procedure. Removing a key does not automatically close an already established shell.
- Disable or delete the account. Lock or expire the account when you need to retain ownership and logs; delete it only after preserving data and confirming that no service depends on it.
- Review evidence. Check SSH authentication logs, sudo logs, deployment systems, and provider audit records for activity during the access period.
For a temporary contractor, set an explicit expiration date at account creation and schedule a review before that date. Expiration is a backstop, not a substitute for removing keys and active sessions when the work ends.
Operational practices that keep access manageable
Maintain a small access register
Record the username, owner, purpose, groups, sudo commands, key fingerprint, creation date, and planned review or expiration date. Store the register where more than one trusted administrator can reach it, but do not store private keys there.
Separate human and automation credentials
Deployment jobs should use a dedicated service identity with its own key and narrowly scoped permissions. Do not put a contractor’s personal key into a continuous-integration system or reuse an automation key for an interactive shell.
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 →Monitor before and after changes
Review successful and failed SSH authentications, sudo events, unexpected group changes, and modifications to authorized_keys. Keep timestamps in a consistent timezone so an incident timeline can be reconstructed accurately.
Rotate deliberately
When a device is lost, a key is exposed, or a contract changes, replace the affected key rather than changing every user’s credential. Test the replacement in a second session before removing the old key, then remove the old key promptly.
Troubleshooting common failures
“Permission denied (publickey)”
- Confirm the client is using the private key that matches the installed public key.
- Check the username and server address; a correct key for another account will still fail.
- Verify ownership and modes on the home directory,
.ssh, andauthorized_keys. - Check that the account’s shell is valid and that an
AllowGroupsrule includes the user. - Read the SSH server log while attempting one connection; it usually identifies the rejected condition.
The developer can log in but cannot perform the task
- Run
idin a new session to confirm group membership was applied. - Check file and directory permissions along the entire path, not only the final file.
- Use
sudo -lto verify the exact command allowed by the policy. - Do not solve a single permission error by adding the user to a broad administrator group; adjust the owning group or one narrowly scoped rule instead.
An SSH change locked out administrators
Do not repeatedly restart the daemon. Use the provider console or recovery path, restore the last known-good configuration, run sshd -t, and test one administrator key before applying hardening again. This is why an out-of-band path must be confirmed before disabling root or password authentication.
Practical decision checklist
- Does every human have a unique Unix username?
- Did each person provide only a public key, with the private key kept passphrase-protected on their device?
- Are application groups and
sudoersrules limited to documented tasks? - Can you identify the exact key and person responsible for every account?
- Is SSH restricted by account group and, where feasible, VPN or source allowlisting?
- Have you tested a second administrator key and provider recovery console?
- Can you remove one person’s keys, grants, sessions, and credentials without changing anyone else’s access?
If any answer is no, fix that control before treating the VPS as ready for outside development access.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
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.
