Skip to content

Security: howdeploy/Xrayebator

Security

docs/security.md

Security

← Back to README · Русский · 简体中文

Sections: Service account and permissions · Subscription security · SSH access to the VPS


Service account and permissions

Xray runs as the system user xray. The drop-in /etc/systemd/system/xray.service.d/security.conf sets User=xray and narrows the capabilities to CAP_NET_BIND_SERVICE, which is enough for low ports. The base unit — created by the installer only when no packaged unit exists — declares a wider bounding set, but the drop-in overrides both directives.

Actual permissions on the state:

Path Owner Mode
/usr/local/etc/xray/ xray:xray recursive
config.json xray:xray 0644
.private_key xray:xray 0600
.public_key xray:xray 0644

In other words, the service account can write to its own config and profiles.

Do not place anything in /usr/local/etc/xray/ that root later executes or sources, and do not keep unrelated secrets there.

Subscription security

The subscription URL is not public. It is protected by an opaque token, but anyone holding the URL can download the route list.

Already handled server-side:

  • a 32 hex character token generated by openssl rand -hex 16;
  • /sub/ without a valid token returns an identical 404;
  • a profile with no live routes returns 410 and serves no routes;
  • nginx adds Cache-Control: no-store;
  • the root / and any path outside /sub/ return 404;
  • the /sub/ location is rate limited;
  • Revoke rotates sub_token.

Left to the operator:

  • do not post the subscription URL in public chats;
  • press Revoke immediately after a leak;
  • never hand a local-only URL to an external client;
  • do not host third-party panels or proxies on the same domain without understanding the nginx config.

SSH access to the VPS

Xrayebator can be installed straight from root, but a dedicated user is the better practice.

On the server:

adduser <username>
usermod -aG sudo <username>
su - <username>

On your own machine:

ssh-keygen -t ed25519 -C <your_email@example.com>
ssh-copy-id <username>@<server_ip>

Then log in as <username>@<server_ip>. Once key-based login works, disable passwords and optionally forbid root login:

sudo nano /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Losing the SSH keys means losing access to the server. Confirm that key-based login works before disabling passwords.

A keep-alive helps the SSH session survive VPN reconfiguration:

ClientAliveInterval 60
ClientAliveCountMax 120
TCPKeepAlive yes

There aren't any published security advisories