← Back to README · Русский · 简体中文
Sections: Service account and permissions · Subscription security · SSH access to the VPS
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.
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 identical404;- a profile with no live routes returns
410and serves no routes; - nginx adds
Cache-Control: no-store; - the root
/and any path outside/sub/return404; - the
/sub/location is rate limited; Revokerotatessub_token.
Left to the operator:
- do not post the subscription URL in public chats;
- press
Revokeimmediately 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.
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_configPermitRootLogin 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