llama.cpp’s RPC worker has no API-key authentication option, although the separate HTTP server supports keys for chat requests. Setting --api-key on llama-server doesn't add that check to the worker.
With the MS-S1 MAX-P495’s dual Ethernet connections, you can put worker traffic on a separate physical link. Choosing a second cable doesn't restrict which network addresses the software listens on.
The RPC backend remains experimental. Its documentation warns against open networks and sensitive environments. Restricting network access doesn't remove those limitations.
Changing the bind address to 0.0.0.0 makes it listen on every local IPv4 address. On a workstation with office and worker connections, this includes both. A firewall may still block access, but the listener itself isn't limited to your private cable.
For a direct link, bind the worker to its address on that link instead. The example --host 192.168.50.2 selects one address. It must be an address actually assigned to that machine.
The bind address chooses a local destination, not an approved caller. Restrict incoming traffic separately by network interface and by the main machine's source address.
An SSH local forward lets you leave the worker on loopback. The SSH service on the worker's machine makes the final connection locally. Bind the tunnel's listening port on your main machine to loopback too.
SSH encrypts and authenticates the connection between its endpoints. It doesn't add a password prompt to RPC. Other machines must not be able to connect to the tunnel's listening port and use your authenticated session.
Loopback isn't a per-user permission. Other processes on the same machine may still connect. Use it on systems whose users and applications you trust.
The default RPC port is 50052. Starting the worker with -p 50053 changes it. A rule for 50052 doesn't control the new listener.
Aim for worker access limited to one trusted machine, not a rule that permits every address on the office subnet. Match the incoming interface, source address, destination address, and TCP port.
In Ubuntu's UFW firewall, a broad rule such as allow 50052/tcp permits connections without restricting the source or interface. Adding a narrower allow rule doesn't revoke the broad permission.
Check that the firewall is active too. UFW starts disabled, and saved rules are not proof that filtering is running. sudo ufw status verbose reports its current state.
Before enabling a restrictive policy over SSH, preserve access for your management connection. Otherwise, an attempted security fix can end your access to the machine.
Containers need a separate check. With Docker bridge networking, publishing a port without a host address binds it to all host addresses by default. The container's own address does not identify which workstation interface accepts outside traffic.
Docker can also divert published-port traffic before it reaches UFW's normal input filtering. An active UFW rule blocking the worker port therefore isn't enough to establish that a containerized worker is unreachable.
Set the host-side published address explicitly and apply restrictions through firewall rules that handle Docker's forwarded traffic. Don't edit Docker's generated rules indiscriminately. Test the published host port, which may differ from the port inside the container.
A failed connection alone isn't enough if you've also stopped the worker. Keep it running during the test so you aren't mistaking an unavailable process for working restrictions.
Test the office-facing address as well as any routed path to the private address. Successful inference from the intended peer proves only that permitted access works.
For the HTTP server, /health deliberately bypasses the API-key check. It can return a healthy response without credentials while protected requests still require a key.
Once the model is ready, submit a valid request to /v1/chat/completions without credentials and expect HTTP 401. Repeat with the configured key to check that an authorized request succeeds.
Ensure the client isn't adding an Authorization or X-Api-Key header automatically. Either header can satisfy the server's key check. A request must omit both to test unauthenticated access.
With the MS-S1 MAX-P495’s dual Ethernet connections, you can put worker traffic on a separate physical link. Choosing a second cable doesn't restrict which network addresses the software listens on.
The RPC backend remains experimental. Its documentation warns against open networks and sensitive environments. Restricting network access doesn't remove those limitations.
A private cable does not narrow a wildcard listener
The worker defaults to 127.0.0.1, which allows connections from the same machine. A second workstation cannot connect directly to that loopback address.Changing the bind address to 0.0.0.0 makes it listen on every local IPv4 address. On a workstation with office and worker connections, this includes both. A firewall may still block access, but the listener itself isn't limited to your private cable.
For a direct link, bind the worker to its address on that link instead. The example --host 192.168.50.2 selects one address. It must be an address actually assigned to that machine.
The bind address chooses a local destination, not an approved caller. Restrict incoming traffic separately by network interface and by the main machine's source address.
An SSH local forward lets you leave the worker on loopback. The SSH service on the worker's machine makes the final connection locally. Bind the tunnel's listening port on your main machine to loopback too.
SSH encrypts and authenticates the connection between its endpoints. It doesn't add a password prompt to RPC. Other machines must not be able to connect to the tunnel's listening port and use your authenticated session.
Loopback isn't a per-user permission. Other processes on the same machine may still connect. Use it on systems whose users and applications you trust.
A broad firewall rule can admit the whole office
On Linux, sudo ss -ltnp shows which TCP ports are listening and which processes own them. Check the worker's real address and port before writing a firewall rule.The default RPC port is 50052. Starting the worker with -p 50053 changes it. A rule for 50052 doesn't control the new listener.
Aim for worker access limited to one trusted machine, not a rule that permits every address on the office subnet. Match the incoming interface, source address, destination address, and TCP port.
In Ubuntu's UFW firewall, a broad rule such as allow 50052/tcp permits connections without restricting the source or interface. Adding a narrower allow rule doesn't revoke the broad permission.
Check that the firewall is active too. UFW starts disabled, and saved rules are not proof that filtering is running. sudo ufw status verbose reports its current state.
Before enabling a restrictive policy over SSH, preserve access for your management connection. Otherwise, an attempted security fix can end your access to the machine.
Containers need a separate check. With Docker bridge networking, publishing a port without a host address binds it to all host addresses by default. The container's own address does not identify which workstation interface accepts outside traffic.
Docker can also divert published-port traffic before it reaches UFW's normal input filtering. An active UFW rule blocking the worker port therefore isn't enough to establish that a containerized worker is unreachable.
Set the host-side published address explicitly and apply restrictions through firewall rules that handle Docker's forwarded traffic. Don't edit Docker's generated rules indiscriminately. Test the published host port, which may differ from the port inside the container.
A healthy chat server proves nothing about worker access
Run two separate checks. From the main workstation, confirm that the model can use its RPC worker. From an excluded machine, a fresh TCP connection to the worker port should fail.A failed connection alone isn't enough if you've also stopped the worker. Keep it running during the test so you aren't mistaking an unavailable process for working restrictions.
Test the office-facing address as well as any routed path to the private address. Successful inference from the intended peer proves only that permitted access works.
For the HTTP server, /health deliberately bypasses the API-key check. It can return a healthy response without credentials while protected requests still require a key.
Once the model is ready, submit a valid request to /v1/chat/completions without credentials and expect HTTP 401. Repeat with the configured key to check that an authorized request succeeds.
Ensure the client isn't adding an Authorization or X-Api-Key header automatically. Either header can satisfy the server's key check. A request must omit both to test unauthenticated access.
