How to Set Up RCON and Keep It Secure

RCON gives full remote control of a Counter-Strike 1.6 server — change level, set any cvar, kick, ban, even shut it down. In GoldSrc it travels over the same UDP port as the game using a challenge-response handshake, and the entire security model is one shared secret: rcon_password. That makes setup easy and makes a leaked password catastrophic. This is how to configure it and how to keep it from becoming your weakest link.

1. Set a strong rcon_password

Put it in cstrike/server.cfg, not on the command line where it shows up in ps:

rcon_password "9Xf2-qbT!m4Lz7vRpKe0"
sv_lan 0

Use at least 16 random characters. RCON has no username and no lockout by default, so length is your only defence against a brute-force attempt against the port. sv_lan 0 is required anyway for a public server, but note that sv_lan 1 also disables RCON entirely.

2. Harden with ReHLDS failure limits

Stock HLDS will answer RCON attempts forever. ReHLDS adds cvars that ban an IP after too many bad passwords. Add them to server.cfg:

sv_rcon_minfailures 5
sv_rcon_minfailuretime 30
sv_rcon_maxfailures 10
sv_filterban 1

These say: if an IP sends sv_rcon_minfailures bad passwords within sv_rcon_minfailuretime seconds, or sv_rcon_maxfailures total, it gets blocked. This turns an unlimited guessing game into a handful of tries. They only exist on ReHLDS — on stock HLDS the feature simply is not there, which is one more reason to run ReHLDS.

3. Protect the file that holds the password

server.cfg is plain text. On Linux, lock down its permissions so other users on the box cannot read it:

chmod 600 /home/steam/hlds/cstrike/server.cfg
chown steam:steam /home/steam/hlds/cstrike/server.cfg

If you run the server as an unprivileged steam user (you should), this keeps the secret to that account. Never commit server.cfg to a public git repo — a surprising number of leaked RCON passwords come from exactly that.

4. Do not hand RCON to your admins

The most common leak is social, not technical: giving the RCON password to every moderator so they can kick people. Do not. Give them AMX Mod X admin flags instead, so each admin authenticates by their own SteamID and you can revoke one person without changing a shared secret. Reserve RCON for yourself and one or two co-owners. If a moderator genuinely needs console-level power, AMXX flag l grants amx_rcon under their own identity — far better than sharing the raw password.

The distinction matters because of accountability. When five people share one rcon_password and a map gets changed at a bad moment or a cvar is quietly altered, you have no way to know who did it. With per-admin flags every action is attributable to a SteamID and shows up in the AMXX admin log. RCON should be the break-glass tool, not the daily driver.

5. Rotate after any exposure

Change the password whenever someone leaves the staff team, whenever it may have been typed on an untrusted machine, and on a routine schedule. Rotation is one line and a reload:

rcon_password "new-long-random-value"

then exec server.cfg from console, or just restart. Because there is no per-user credential, rotation is the only way to cut off a leaked password.

Common errors

• Bad rcon_password. — the client-side password does not match the server. Set it on the client with rcon_password "..." before sending commands; see the bad rcon_password fix.
• RCON does nothing at all — sv_lan 1 disables it, or the password is empty (an empty rcon_password means RCON is off, not open).
• Failure-limit cvars rejected as unknown — you are on stock HLDS, not ReHLDS. Those cvars are ReHLDS-only.
• Locked yourself out — you tripped your own sv_rcon_maxfailures from the same IP while testing. Restart the server (console access is unaffected) to clear the block.
• Password visible in process list — you passed +rcon_password on the command line. Move it into server.cfg.

Verification

From a client console on another machine:

rcon_password "9Xf2-qbT!m4Lz7vRpKe0"
rcon status

A correct password returns the player list; a wrong one returns Bad rcon_password. Then confirm the hardening works: from a throwaway IP, send several deliberately wrong passwords and check the server log records the failures and eventually blocks the address. Once both the positive and the lock-out paths behave, RCON is set up correctly. Next, learn the day-to-day commands in essential RCON commands.