How to share SSH access without sharing your private key

Ask each person for their public key and add it to the server: in their own account, or as a separate line in the shared account's ~/.ssh/authorized_keys. Your private key stays on your device, logs show whose key was used, and removing one person means deleting one line. For temporary access, add expiry-time= to the line or sign a short-lived SSH certificate.

Updated . Run with OpenSSH 10.0 on Debian 13 in a throwaway container: per-person accounts with install, a shared account with one line per person and expiry-time (an expired line was refused), a user certificate signed with -V +8h and accepted through TrustedUserCAKeys, removing a line, usermod --expiredate and pkill.

Why not just share the key

Sending a teammate your private key, or a copy of a deploy key everyone uses, works on day one and causes trouble later:

  • The server sees one key, so its logs cannot say who did what.
  • When one person leaves, the only way to remove them is a new key for everyone.
  • Every copy in a laptop, a chat history or a backup is one more place it can leak from.

SSH is built for the opposite: each person has their own key pair, keeps the private half, and hands out only the public half. A server can trust as many public keys as you like.

One account per person

The cleanest setup gives each person their own Linux account. Ask for their public key, then on the server:

sudo adduser --disabled-password --gecos "" bob
sudo install -d -m 700 -o bob -g bob /home/bob/.ssh
sudo install -m 600 -o bob -g bob bob.pub /home/bob/.ssh/authorized_keys

On RHEL and similar systems use sudo useradd -m bob for the first line. Add the account to the sudo or wheel group only if they need root, as described in creating a user with SSH access and sudo. Every command is then tied to a name, and files keep their owner.

Several people on one shared account

Sometimes everyone has to log in as the same user, such as deploy or the default user of a cloud image. Then give each person their own line in that account's authorized_keys, with a comment naming them:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGk3... alice@laptop
expiry-time="20261231" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJq8... bob@laptop

The expiry-time option makes Bob's line stop working after that date, with nothing to remember. Other options limit a key to some addresses or one command, see restricting an SSH key. Because each person has a different key, the server log still tells them apart by fingerprint:

Accepted publickey for deploy from 203.0.113.25 port 51234 ssh2: ED25519 SHA256:vsze5ORPbYF/MMM4TTtuyy6yiEAYV1CcI4FOF0dV9wI

List the fingerprints in the file to see whose key that is:

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Short-lived access with certificates

With many servers and frequent changes, editing authorized_keys everywhere gets old. An SSH certificate authority solves it: servers trust the CA once, and you sign each person's public key for a set time.

ssh-keygen -t ed25519 -f user_ca -C "team user CA"
ssh-keygen -s user_ca -I bob@example.com -n deploy -V +8h bob.pub

This creates bob-cert.pub, valid for eight hours as the user deploy. On each server, copy user_ca.pub to /etc/ssh/user_ca.pub and add one line to sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Bob keeps bob-cert.pub next to his private key and logs in as usual. When it expires, access ends without touching any server. Keep the CA key offline or in a dedicated system, since it can sign access to everything. The full setup is in SSH certificates explained.

Take access away

For a key line, delete it. Deleting by comment is quick; for a thorough cleanup search by fingerprint, as shown in revoking an SSH key when someone leaves:

sudo sed -i.bak '/ bob@laptop$/d' /home/deploy/.ssh/authorized_keys

For a personal account, lock it so neither key nor password works, then end anything still running:

sudo usermod --expiredate 1 bob
sudo pkill -KILL -u bob

Removing a key does not close sessions already open, so do not skip the second command. Then change any password, token or shared key the person knew.

Show someone your terminal live

Sometimes the need is not access but help: someone should watch you work, or type for a minute. On a server where you both have accounts, tmux can share one session. Create a group for it and start tmux on a socket that group can reach:

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob
tmux -S /tmp/pair new -s pair

From another window, open the socket to the group and allow Bob in. tmux 3.3 and later refuse other users until you do:

chgrp pair /tmp/pair
chmod 770 /tmp/pair
tmux -S /tmp/pair server-access -a bob
tmux -S /tmp/pair server-access -r bob

The last line makes Bob read-only; leave it out to let him type. He joins with tmux -S /tmp/pair attach -t pair. When you are done, tmux -S /tmp/pair server-access -d bob removes him. Both people need an account on that server, and anything Bob types runs as you.

Shared passwords and other secrets

Some things cannot be split per person: a network device with one admin password, a database root password, a deploy key for a repository. Keep them in a password manager or vault the team shares, not in chat or a wiki page, so you know who can read them. When someone leaves, change each secret they could see, because removing their access to the vault does not erase what they already copied.

Questions

Can two people use the same SSH private key?

Technically yes, but then the server cannot tell them apart, and taking access away from one means replacing the key for everyone. Give each person their own key instead.

Is it safe to send a public key by email or chat?

Yes. A public key is meant to be shared. Only the private key, the file without .pub, must stay on its owner's device.

How do I give someone access for a few days only?

Put expiry-time="20261231" in front of their key in authorized_keys, or sign their key as a certificate with ssh-keygen -s and a validity such as -V +3d. Both stop working on their own.

Can I let someone see my terminal without giving them access?

Yes. With tmux, a shared socket and server-access -r, they can watch read-only. They still need an account on the same server to attach.

Sources

More in Securing a server

All guides