---
title: "How to Set Up RCON and Keep It Secure"
excerpt: "Configure rcon_password on a CS 1.6 server the right way, harden it with ReHLDS failure-limit cvars, and stop leaking the password to your own admins."
category: "administration"
tags: "rcon, security"
image: ""
read_time: "8 min read"
---
<p>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: <code>rcon_password</code>. 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.</p>

<h2>1. Set a strong rcon_password</h2>
<p>Put it in <code>cstrike/server.cfg</code>, not on the command line where it shows up in <code>ps</code>:</p>
<pre>rcon_password "9Xf2-qbT!m4Lz7vRpKe0"
sv_lan 0</pre>
<p>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. <code>sv_lan 0</code> is required anyway for a public server, but note that <code>sv_lan 1</code> also disables RCON entirely.</p>

<h2>2. Harden with ReHLDS failure limits</h2>
<p>Stock HLDS will answer RCON attempts forever. <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> adds cvars that ban an IP after too many bad passwords. Add them to <code>server.cfg</code>:</p>
<pre>sv_rcon_minfailures 5
sv_rcon_minfailuretime 30
sv_rcon_maxfailures 10
sv_filterban 1</pre>
<p>These say: if an IP sends <code>sv_rcon_minfailures</code> bad passwords within <code>sv_rcon_minfailuretime</code> seconds, or <code>sv_rcon_maxfailures</code> 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.</p>

<h2>3. Protect the file that holds the password</h2>
<p><code>server.cfg</code> is plain text. On Linux, lock down its permissions so other users on the box cannot read it:</p>
<pre>chmod 600 /home/steam/hlds/cstrike/server.cfg
chown steam:steam /home/steam/hlds/cstrike/server.cfg</pre>
<p>If you run the server as an unprivileged <code>steam</code> user (you should), this keeps the secret to that account. Never commit <code>server.cfg</code> to a public git repo — a surprising number of leaked RCON passwords come from exactly that.</p>

<h2>4. Do not hand RCON to your admins</h2>
<p>The most common leak is social, not technical: giving the RCON password to every moderator so they can kick people. Do not. Give them <a href="/tutorials/users-ini-explained">AMX Mod X admin flags</a> 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 <code>l</code> grants <code>amx_rcon</code> under their own identity — far better than sharing the raw password.</p>
<p>The distinction matters because of accountability. When five people share one <code>rcon_password</code> 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.</p>

<h2>5. Rotate after any exposure</h2>
<p>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:</p>
<pre>rcon_password "new-long-random-value"</pre>
<p>then <code>exec server.cfg</code> from console, or just restart. Because there is no per-user credential, rotation is the <em>only</em> way to cut off a leaked password.</p>

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

<h2>Verification</h2>
<p>From a client console on another machine:</p>
<pre>rcon_password "9Xf2-qbT!m4Lz7vRpKe0"
rcon status</pre>
<p>A correct password returns the player list; a wrong one returns <code>Bad rcon_password.</code> 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 <a href="/tutorials/rcon-commands-list">essential RCON commands</a>.</p>