SSH access to remote servers

The SSH access module lets you service a second server (for example, the node server) right from the script menu on the panel: update packages, restart the node container, read logs, without opening a second SSH session. Another module, server routing, uses this access automatically when it installs a node on the second server.

The password is asked once

The script installs its own key and forgets the password: it is never written to disk.

Your key is never read

An existing key is used in place; its contents are not copied or opened.

One line in authorized_keys

The script’s key lives on its own line marked remnawave-reverse-proxy; your lines are untouched.

The menu item lives at 4. Node extensions → SSH access to remote servers.

How it works

The panel server keeps the list of targets (nodes known to the panel, or addresses entered manually) and the SSH keys. During setup the script installs its own key on the target once, using the password; after that the password is never needed again. Every operation runs over the key: running commands, updating a node, and configuring exit servers for server routing.

What the module looks like

On first entry the list is empty and the module offers to set up the first server right away:

root@server: ~

SSH Remote Access
 Details in the wiki: https://wiki.egam.es/configuration/ssh-remote-access

 Not configured

1.Set up access

0.Exit

Select action (0-1):

Once servers exist, the list looks like this, with labels and a note about which key is used:

root@server: ~

SSH Remote Access
 Details in the wiki: https://wiki.egam.es/configuration/ssh-remote-access

 Configured servers: 2

1.root@203.0.113.20:22 (Kazan) (our key)
2.root@203.0.113.5:22 (Frankfurt) (our key)

3.Set up another server

0.Exit

Select action (0-3):

There is no limit on servers. Each one can get a label shown next to the address in the list, renameable at any moment. The key is the same for all servers (the panel is a single access point), but each server keeps its own line in authorized_keys.

First-time setup

1. Pick the server address. The script first asks for the address by hand, and if the panel already knows nodes, it shows them as a list to pick a ready address:

   root@server: ~

   Server address (IP or domain): 203.0.113.20
   
   Nodes known to the panel
   
   1.node.example.com (node-kazan)
   2.Enter an address manually

2. Port, user and label. Port and user can be left at the defaults: Enter fills in 22 and root. The label is the server’s name in the list:

   root@server: ~

   SSH port (Enter — 22): 22
   SSH user (Enter — root): root
   Server label in the SSH connections list (Enter — no label): Kazan

3. Probing existing keys. If this server already holds a key that opens the second server, the script takes it silently: no questions, nothing changed on the remote side. If no key works, it offers three paths:

   root@server: ~

   Trying keys already present on this server...
   No existing key works for that server
   
   No key worked — choose how to proceed
   
   1.Point at an existing key on this server
      the file is used in place, its contents are never read
   2.Enter the root password once
      only used to install our own key, then discarded
   3.Show our public key for manual setup
      for servers with password login disabled
   
   Select action (1-3):

   • Your own key: point at its path, the file is used in place.
   • Root password once: the script asks for the password (hidden input), installs its own separate key and forgets it.
   • Manual paste: for servers with password login disabled, the script shows its public key and the command to run on the second server. The check repeats on EnterEnterEnterEnterEnterEnter, waiting exits with QQQQQQ.

4. Installing the key with a password looks like this:

   root@server: ~

   Root password of 203.0.113.20 (input hidden): 
   Installing our key on 203.0.113.20...
   Key installed — the password is no longer needed
   
   Access saved: root@203.0.113.20:22

Check after setup

The module offers to test the connection right away and show the remote server’s hostname:

root@server: ~

Connection works (remote host: node-kazan)

If you see it, access works.

If the server was reinstalled

On a host key mismatch the script never connects silently: it shows the fingerprint the server presents and asks for confirmation:

root@server: ~

The host key of 203.0.113.20:22 differs from the one saved in known_hosts: the server was reinstalled or the address now belongs to another server
The server presents key ED25519 SHA256:9Xk…, verify it against the output on the server itself:
  ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Forget the old host key and reconnect? (y/n): y

Server menu

Picking a server from the list opens its menu:

root@server: ~

SSH Remote Access

 Name: Kazan
 Configured: root@203.0.113.20:22
 Key: our key

1.Test connection
2.Run a command
3.Rename
4.Reconfigure
5.Revoke access

0.Exit

Select action (0-5):

Running commands

The Run a command item executes a command on the remote server, the output lands in your terminal, and the script prints the exit code at the end:

root@server: ~

Command to run on root@203.0.113.20:22: docker logs remnanode --tail 5
… command output …
Command finished (exit code 0)
Enter returns to the menu...

Typical scenarios:

Update packages on the remote server

apt update && apt upgrade -y

Update the node (commands start in /root, compose needs cd)

cd /opt/remnanode && docker compose pull && docker compose up -d

Node logs

docker logs remnanode --tail 50

Limitations

Interactive programs (top, nano, mc) will not work: no terminal is allocated on the remote side. To check status, use plain commands with text output: docker logs, free -h, df -h.

Under the hood: where it is stored

All access data lives on the panel in /usr/local/remnawave_reverse:

• Directory/usr/local/remnawave_reverse

  • Directoryremote-exec

    • 203.0.113.20_22.target (server: address, port, user, key, label)
    • 203.0.113.5_22.target
  • remote-exec.active (which server was used last)
  • Directoryssh

    • id_ed25519 (the script’s key, one for all servers)
    • known_hosts

The .target files are plain key=value; edit them by hand only as a last resort: the rename and reconfigure menus do the same thing safely.

Revoking access

The Revoke access item first explains what will happen and asks for confirmation:

root@server: ~

The panel's line will be removed from authorized_keys on the server and the server will disappear from this list: the panel will no longer be able to SSH into it. The node and the server keep working. The service key is wiped only if no other server uses it
Revoke SSH access to root@203.0.113.20:22 (Kazan)? (y/n): y
Revoking...
Access revoked

Your own access to the server does not change in any way.

---

Server routing (bridge)Splitting traffic between two servers: this access is used there automatically.