Skip to content
Local Panel logo Local Panel by Nesdzo Get Local Panel

25 October 2026 · 5 min read

How to Give a Developer Access to Your Server (Without Sharing Your Password)

At some point, almost every server owner needs to give a developer access to their server. A freelancer is fixing a broken deployment. An agency is migrating a site. A colleague is covering while you are away.

And almost every time, the same bad habit appears: the root password, pasted into a chat message.

It is quick, and it works, which is why people keep doing it. It is also a quietly terrible idea. Whoever has that password has your server, full stop. They can read every database, change every file and create accounts you will never know about. The password now lives in a chat history you do not control, on a machine you do not own. Revoking access means changing the password and hoping it was not saved anywhere else. And if that password is reused elsewhere — as passwords usually are — the damage spreads further.

There are better ways to share SSH access. This post walks through three of them, honestly, including the fiddly one.

Option 1: Share SSH access the manual way

The "proper" manual approach is well documented. You create a dedicated user for the developer, give them only the access they need, and authenticate them with an SSH key instead of a password. On a Linux server, the steps look roughly like this.

Create the user:

sudo adduser developer

Set up their SSH directory and add the public key they send you:

sudo mkdir -p /home/developer/.ssh
sudo nano /home/developer/.ssh/authorized_keys

Fix the permissions — this is the step everyone gets wrong, and the one that causes most "it won't let me in" messages:

sudo chown -R developer:developer /home/developer/.ssh
sudo chmod 700 /home/developer/.ssh
sudo chmod 600 /home/developer/.ssh/authorized_keys

If they need elevated rights, you can grant limited sudo instead of everything. A sensible middle ground is passwordless sudo for the package manager and web server directories, configured in /etc/sudoers.d/. Resist the urge to just add them to the sudo group and walk away.

When the job is done, you revoke access properly:

sudo deluser --remove-home developer

None of this is difficult, but it is fiddly. It assumes you are comfortable on the command line, that you can get a public key from the developer over a trustworthy channel, and that you remember to revoke the account when the work is finished. Most people remember three weeks later, if at all. If you both spend your days in a terminal, it is worth doing — our round-up of the best SSH clients for Mac and Windows covers the tools we would reach for. But if you manage servers from a desktop app, there is a lower-friction route.

Option 2: Screen sharing and passwords in notes

Two other shortcuts deserve a mention, mostly because they fail in instructive ways.

Screen sharing means the developer drives your machine while you watch. It feels safe because you can see everything, but everything they do is logged as you. Any action they take is indistinguishable from your own, which makes auditing pointless, and it is painfully slow for real work. Sharing your password through a notes app, a text file or an email is no better than chat: the password persists forever, on someone else's device, with no expiry and no revocation.

Neither option answers the two questions that matter: can you see what was done, and can you make it stop?

Option 3: Share server access securely with a one-time code

Local Panel, our desktop control panel for SSH and VPS management, was built around exactly this problem. Its Safe Share feature lets you hand a server to a colleague through a one-time code: they enter it in their own copy of Local Panel, connect directly to the server over SSH, and do their work. When the job is done — or whenever you choose — you revoke the share and it is gone. There is no shared password, no leftover account, and nothing to clean up on the server afterwards.

For longer engagements, Share Your Server gives someone time-boxed access that you can revoke at any moment, with the same direct SSH connection and the same nothing-left-behind ending. Because connections run straight from the desktop app to your server, and because your own credentials stay encrypted in your device's keychain, nothing passes through or sits on anyone else's infrastructure.

The Safe Share documentation and the Share Your Server guide walk through both flows step by step.

Whichever method you used: a revoke checklist

Granting access is only half the job. When the work is finished, run through this list — it applies whatever approach you took:

  1. Remove the user account you created, along with their home directory (sudo deluser --remove-home developer).
  2. Remove their key from ~/.ssh/authorized_keys on every account it was ever added to — including root.
  3. Rotate any password that was shared, however briefly, and anywhere it was reused.
  4. Check for persistence tricks: cron jobs, new sudo entries in /etc/sudoers.d/, extra users, and unexpected listening ports.
  5. Delete the share, code or note through which access was granted, and confirm the other person no longer connects.

Two minutes of tidying now saves a very uncomfortable discovery later.

The short version

Pasting your root password into a chat is convenient exactly once. The manual route is solid but demands discipline. Safe Share exists for everyone else: a one-time code, a temporary connection, and a revoke button — which is really what sharing access securely comes down to.

Local Panel is a one-off payment of £59.99 with no subscription, and Local Panel Lite is completely free, forever. Download it from the download page and try Safe Share on your own servers.

Wondering how Safe Share stacks up against dedicated access tools? See our honest comparison of Teleport, Tailscale, Boundary, Cloudflare Access and Termius.