Server access for colleagues and outside developers

How to give a colleague or a freelancer access to your server without sharing your account, the root password or tokens: SSH keys, separate users, SFTP-only access and revoking access.

This guide shows how to give a colleague or an outside developer access to your server without sharing your blackbox.md account, the root password or your API tokens. You add the colleague's key for root in the app.blackbox.md panel, on the server card in “My Servers” (app.blackbox.md/my-servers, left menu “Infrastructure” → “My Servers”). Separate users and SFTP-only access are set up on the server itself, over SSH, as root.

Available to: the blackbox.md account holder who ordered the server, or an account that BLACKBOX has given management rights for the server (the steps in the panel), and anyone with root SSH access to the server (the steps on the server). On cards marked “Managed”, the “Add SSH key” and “Reset password” buttons do not appear; for these servers, write to us.

What the account and the panel provide

The blackbox.md account and the panel have no team members, sub-users, roles or invitations sent by customers. Each person uses their own blackbox.md account.
A colleague with their own account does not see your orders, invoices, support tickets or servers, and cannot sign in to the panel in your place. They do not need an account for SSH or SFTP access.
Shared access to the servers of a company managed by BLACKBOX (the “Managed” cards) is granted only on request, through support: The “Overview” page.
The “Installed keys” list and the “Add SSH key” button work only with the /root/.ssh/authorized_keys file. You manage the keys of other Linux users directly on the server.

Do not share	Why
Your blackbox.md account password	With it, someone can place and pay for orders, open the panel and create API tokens.
The root password	It gives full control of the server, and with a shared password you can't tell who did the work.
API tokens (`bbx_pat_…`)	They act as the account holder: with the `servers:exec` permission they run any command as root, and with `orders:write` they place orders and pay from your balance (Token permissions (scopes)).
2FA recovery codes	They replace the code from your authenticator app when signing in to the panel.
Private SSH keys	A private key never leaves its owner's computer: don't send yours, and don't accept anyone else's private key.

Under the Terms and Conditions (§3), you are fully responsible for the activity of everyone you authorize to access the services (employees, contractors) and for securing passwords, SSH keys and API tokens.

Your colleague generates their own key pair (Generating an SSH key (Windows, macOS, Linux)) and sends you only the public key: a single line from the .pub file. Ask them to put their name in the key's comment, so you can recognize it in “Installed keys”:

ssh-keygen -t ed25519 -C "COLLEAGUE_NAME"

Also ask for the key's fingerprint, so you can compare it with the one installed on the server. On macOS and Linux:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

On Windows (PowerShell):

ssh-keygen -lf $env:USERPROFILE\.ssh\id_ed25519.pub

Which access to choose

What your colleague needs	Solution	Where
Full administration of the server	Their public key for `root`, added with “Add SSH key” → “Paste a new key”; you remove it from “Installed keys”	panel
Administration with their own login, so you can see who did what	A separate Linux user in the `sudo` group (Ubuntu, Debian) or the `wheel` group (AlmaLinux, CentOS Stream)	server
Only the site's files	An SFTP-only user, limited to the site's directory	server
Only the database	A separate user without `sudo`, plus an SSH tunnel (Databases: MariaDB/MySQL and PostgreSQL)	server

Your colleague's key for root, from the panel

On the server card in “My Servers”, click “Add SSH key”.
Choose “Paste a new key” and paste the line you received from your colleague (ssh-ed25519 AAAA… COLLEAGUE_NAME).
Click “Add key”. “Key added.” appears, and the key shows up in “Installed keys” with its comment.
Compare the beginning of the fingerprint in the list with the fingerprint your colleague sent you.
Your colleague connects:
```
ssh root@SERVER_IP
```

The pasted key is installed only on this server and is not saved in your account. The list and its messages are covered in Adding and removing SSH keys on the server.

Important A key for root means full control: your colleague can read all the data, add other keys and users, and change any setting. Ask them not to delete the “Management key (blackbox.md)” and not to set PermitRootLogin no: either of these stops password resets, key management and the password login buttons in the panel (BLACKBOX keys on your server).

A separate Linux user for your colleague

A separate user has their own login: the logs show their name and the commands they run with sudo. The steps are similar to step 5 in Securing a new server: checklist, except that it is your colleague's key that goes on the server, not the root keys. Run the commands as root.

Ubuntu and Debian

adduser --disabled-password USERNAME

The command also creates the /home/USERNAME directory. You can leave the fields it asks for (full name, phone, etc.) empty. The user has no password and logs in only with the key.

AlmaLinux and CentOS Stream

useradd -m USERNAME

Here too, the user gets no password: they log in only with the key.

Your colleague's public key

Create the directory and open the keys file:
```
mkdir -p /home/USERNAME/.ssh
nano /home/USERNAME/.ssh/authorized_keys
```
If nano is missing (this can happen on AlmaLinux and CentOS Stream), install it:
```
dnf install -y nano
```
Paste your colleague's public key on a single line, save with Ctrl + O and Enter, then exit with Ctrl + X.

Set the owner and permissions:

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

On AlmaLinux and CentOS Stream, also restore the SELinux label:

restorecon -R /home/USERNAME/.ssh

Compare the fingerprint shown with the one your colleague sent you:
```
ssh-keygen -lf /home/USERNAME/.ssh/authorized_keys
```

Do not copy /root/.ssh/authorized_keys to the new user: it contains your keys and the BLACKBOX keys.

Administrator rights (only if needed)

Members of the sudo group (Ubuntu, Debian) or the wheel group (AlmaLinux, CentOS Stream) can run any command as root. sudo asks for the user's password, so set one.

Ubuntu and Debian:

passwd USERNAME
usermod -aG sudo USERNAME

On Debian, if the sudo command is missing, install it:

apt install -y sudo

AlmaLinux and CentOS Stream:

passwd USERNAME
usermod -aG wheel USERNAME

Send the password separately from the rest of the access details, and ask your colleague to change it with passwd the first time they log in. On a “Password + key” server, your colleague could also log in over SSH with this password; to switch to “Key-only”, see Enabling and disabling SSH password login. You can see the commands run with sudo in the log:

journalctl _COMM=sudo

Test the login together with your colleague before you hand over access, with your own root session open. In that session, watch the SSH log. On Ubuntu and Debian:

journalctl -u ssh -f

On AlmaLinux and CentOS Stream:

journalctl -u sshd -f

Your colleague connects:

ssh USERNAME@SERVER_IP

A line Accepted publickey for USERNAME appears in the log, with the key's fingerprint; stop watching with Ctrl + C. If you gave them administrator rights, your colleague runs the command below, which must print root:

sudo whoami

On a “Key-only” server, your colleague logs in only with the key. Do not turn password login back on for them: “Enable password login” turns it on for all users, including root.

Only the database

Create the user as above, without administrator rights. So that they can open only the tunnel, not a terminal:

usermod -s /usr/sbin/nologin USERNAME

Your colleague starts the tunnel with their username (for PostgreSQL, replace 3306 with 5432):

ssh -N -L 3306:127.0.0.1:3306 USERNAME@SERVER_IP

The tunnel goes through the SSH port (22), so the database port does not need to be open. In the database, create a separate user for them with only the privileges they need: Databases: MariaDB/MySQL and PostgreSQL.

SFTP-only access to the site's files (optional)

Your colleague can only upload and download files in the site's directory: they get no terminal and cannot open tunnels. The example assumes the site is in /var/www/DOMAIN. SSH confines your colleague to the /srv/sftp/USERNAME directory, which belongs to root and which your colleague cannot change. Inside it, the site subdirectory shows the site's directory, where your colleague can write.

On “VPS hosting” plans, ask support first: the control panel on the server may have its own SFTP accounts and settings (“VPS hosting” plans with a control panel).

Warning Steps 4 and 5 change the SSH settings. Keep your current root session open until you have logged in again as root from a new terminal. Customers have no web or VNC console: if you lose SSH access, only support can help.

Create the group (once, for all SFTP users) and the user.

Ubuntu and Debian:
```
groupadd sftponly
adduser --disabled-password --shell /usr/sbin/nologin USERNAME
usermod -aG sftponly USERNAME
```
AlmaLinux and CentOS Stream:
```
groupadd sftponly
useradd -m -s /usr/sbin/nologin -G sftponly USERNAME
```
Then add your colleague's key as in the “Your colleague's public key” section above.
Create your colleague's directory and make a copy of the /etc/fstab file:
```
mkdir -p /srv/sftp/USERNAME/site
chown root:root /srv/sftp /srv/sftp/USERNAME
chmod 755 /srv/sftp /srv/sftp/USERNAME
cp /etc/fstab /etc/fstab.bak
nano /etc/fstab
```
At the end of the /etc/fstab file, add the line below and save:
```
/var/www/DOMAIN /srv/sftp/USERNAME/site none bind,nofail 0 0
```
Mount the site's directory and check that you can see its files:
```
systemctl daemon-reload
mount /srv/sftp/USERNAME/site
ls /srv/sftp/USERNAME/site
```
The line in /etc/fstab restores the mount after every reboot. Thanks to nofail, a mistake in it does not stop the server from booting.
Allow writing to the site. The site's files must belong to the web server user: see Transferring files to the server (scp, rsync, SFTP), section “After uploading a site: owner and permissions”. Find out their group:
```
stat -c '%U:%G' /var/www/DOMAIN
```
The result is usually www-data:www-data on Ubuntu and Debian, and apache:apache or nginx:nginx on AlmaLinux and CentOS Stream. If you see root:root, first change the owner as described in that section. Then run the commands below, with the group after the : in place of WEB_GROUP:
```
usermod -aG WEB_GROUP USERNAME
chmod -R g+w /var/www/DOMAIN
find /var/www/DOMAIN -type d -exec chmod g+s {} +
```
The files your colleague uploads belong to them and to the web server's group, which can read them. If the application also needs to change them, set the owner again as in the file transfer guide, then run the last two commands again.
Make a copy of the SSH settings and open the main file:
```
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
nano /etc/ssh/sshd_config
```
Add the block below at the end of the file and save:
```
Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /site
    AllowTcpForwarding no
    X11Forwarding no
```
The block must stay last in the file: everything after Match applies only to the sftponly group. %u is replaced with the username, and -d /site opens your colleague directly in the site's directory.
- Do not add PasswordAuthentication to the block: you control password login from the panel.
- Do not set PermitRootLogin no, and do not change the file the panel writes in /etc/ssh/sshd_config.d/.
Check the settings:
```
sshd -t
```
If the command prints nothing, the settings are correct. Only then reload SSH:
```
systemctl reload ssh || systemctl reload sshd
```
If sshd -t prints an error, do not reload SSH: fix the file or restore the copy, then check again with sshd -t.
```
cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
```
From a new terminal, check that you can still log in as root. Then ask your colleague to connect with an SFTP client, for example FileZilla or WinSCP, using the username USERNAME and their key, or from a terminal:
```
sftp USERNAME@SERVER_IP
```
Your colleague lands in /site and sees nothing outside the /srv/sftp/USERNAME directory. If they try ssh, they get “This service allows sftp connections only.” and the connection closes.

If something doesn't work, read the latest messages from the SSH service. On Ubuntu and Debian:

journalctl -u ssh -n 50

On AlmaLinux and CentOS Stream:

journalctl -u sshd -n 50

Problem	Cause	What to do
The connection closes immediately; the log shows `bad ownership or modes for chroot directory`	`/srv/sftp` or `/srv/sftp/USERNAME` does not belong to `root`, or others can modify it	Repeat the `chown` and `chmod` commands from step 2
`Permission denied` when uploading a file	Your colleague is not in the web server's group, or the directory does not allow the group to write	Repeat step 3; your colleague reconnects so the new group applies
The `/site` directory is empty	The site's directory is not mounted	Run the `mount` command from step 2 again
AlmaLinux or CentOS Stream: the login fails, without the messages above	It may be blocked by SELinux	Look for the cause in the `sshd` service log (the command above); if you can't find it, write to us

Revoking access

When the work is finished or the person leaves, revoke their access right away.

The key for root

On the server card, click “Add SSH key”.
In “Installed keys”, find your colleague's key by its comment and fingerprint, and click “Remove”.
Confirm “Remove key SHA256:… from this server?” with “OK”. “Key removed.” appears.
Click “Reset password” and confirm “Reset the password for SERVER_NAME? The current password stops working immediately.”: while they had access, your colleague could have changed the root password (Resetting the root password).

The separate user

Close their open sessions:

pkill -KILL -u USERNAME

Then delete the user together with their directory. Ubuntu and Debian:

deluser --remove-home USERNAME

AlmaLinux and CentOS Stream (and Ubuntu or Debian, if deluser asks for the perl package):

userdel -r USERNAME

The SFTP-only user

First close their sessions with pkill, as above. Before you delete the user, unmount the site's directory, delete the user's line from /etc/fstab and remove the directories that are left empty:

umount /srv/sftp/USERNAME/site
nano /etc/fstab
rmdir /srv/sftp/USERNAME/site /srv/sftp/USERNAME

Risk Do not use rm -r in /srv/sftp. While the site's directory is mounted there, the command would delete the site's actual files. rmdir deletes only empty directories, so it refuses if the mount is still active.

Checks after someone leaves

Look for keys, users and administrator rights you don't recognize. “Installed keys” shows only the root keys.

cat /root/.ssh/authorized_keys
ls -la /home/*/.ssh/authorized_keys
ls -la /etc/sudoers.d/
getent group sudo wheel

Change the secrets the person knew: database passwords (and delete the database user created for them), application keys, for example in .env or wp-config.php, SMTP passwords and the keys of external services.
Check recent logins:
```
last -n 20
```
On Ubuntu and Debian:
```
journalctl -u ssh --since "30 days ago" | grep Accepted
```
On AlmaLinux and CentOS Stream:
```
journalctl -u sshd --since "30 days ago" | grep Accepted
```
The Accepted lines show the user, the IP address and the authentication method. If last is missing, use only journalctl.

If you suspect the access was misused, follow Your server was hacked or is under attack: what to do.

Frequently asked questions

Can my colleague see the server in their own panel? No. A server ordered on blackbox.md appears only in the account that ordered it and cannot be shared in the panel. Only the servers of a company managed by BLACKBOX can be shared, on request, through support (How to contact BLACKBOX support).

A freelancer is asking for the root password or my account details. What do I do? Don't give them out. Add their public key for root or create a separate user for them. If you have already shared them, click “Reset password” on the server card and change your account password, which also stops any API tokens created before (Security recommendations for your account). Then do the checks in the “Checks after someone leaves” section.

How do I know whose key is in “Installed keys”? The list shows the beginning of the fingerprint, the type and the comment of each key. Ask your colleague to put their name in the comment when they generate the key, and compare the fingerprint with the one they sent you: anyone can write a comment, but a fingerprint cannot be faked.

Can I give my colleague an API token for the AI assistant? Don't. The token acts on your behalf, as the account holder: with servers:exec it runs commands as root on all your servers, and with orders:write it places orders and pays from your balance. Your colleague works with their own SSH access.

Does my colleague need a blackbox.md account? No. For SSH or SFTP, their key and the access you give them on the server are enough. An account of their own does not show them your servers.