Add 4 tutorials (4 files)
Browse Source
Daemon666 committed
parent 3dbae2529f
commit 4b97e6dc76eddd1d98bad50c7da3bd7bb544270b
4 changed files
with 223 additions and 0 deletions
A
cs16-config-cfg-guide/en.md
+22 -0
A
do-server-boost-services-work/en.md
+56 -0
A
essential-server-cvars/en.md
+92 -0
A
rcon-setup-secure/en.md
+53 -0
cs16-config-cfg-guide/en.md
A
| @@ -0,0 +1,22 @@ | ||
| 1 | +--- | |
| 2 | +title: "config.cfg Explained: Editing Your CS 1.6 Config" | |
| 3 | +excerpt: "Where config.cfg lives, why your edits keep disappearing, and how to use autoexec.cfg and userconfig.cfg so your settings actually stick across restarts." | |
| 4 | +category: "client" | |
| 5 | +tags: "config.cfg, settings" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>Nearly every "my settings reset every time I launch" complaint comes down to one fact people do not know: the game rewrites <code>config.cfg</code> when it exits. Edit it while CS is running and your changes are gone the moment you quit. Once you understand how the config files load, editing CS 1.6 becomes straightforward and permanent. This guide covers where the files are, the order they run in, and the right place to put your settings.</p><h2>1. Where config.cfg lives</h2><p>The file is inside your Counter-Strike install, in the game folder:</p><pre>...\Steam\steamapps\common\Half-Life\cstrike\config.cfg</pre><p>On Linux the path uses forward slashes but the layout is identical: <code>Half-Life/cstrike/config.cfg</code>. If you play a mod, that mod has its own folder (for example <code>czero</code>) with its own <code>config.cfg</code>.</p><h2>2. What is inside it</h2><p><code>config.cfg</code> is a plain list of console commands the engine runs at startup. It holds your key binds, your rates, your mouse sensitivity and your video-related cvars — essentially your whole setup as commands:</p><pre>bind "w" "+forward" | |
| 10 | +bind "mouse1" "+attack" | |
| 11 | +sensitivity "2.2" | |
| 12 | +rate "100000" | |
| 13 | +cl_updaterate "101" | |
| 14 | +cl_cmdrate "101" | |
| 15 | +ex_interp "0.01" | |
| 16 | +fps_max "300"</pre><p>You can read it to see exactly what the game thinks your settings are — it is the source of truth the menu writes to.</p><h2>3. The golden rule: edit with the game closed</h2><p>The engine loads <code>config.cfg</code> at startup and <strong>writes it back on exit</strong>, overwriting your file with its in-memory state. So:</p><ol><li>Fully quit Counter-Strike.</li><li>Open <code>config.cfg</code> in a plain text editor (Notepad, not a word processor).</li><li>Make your changes and save.</li><li>Launch the game.</li></ol><p>Edit it while the game is open and you are wasting your time — this single mistake is behind the vast majority of "my config keeps resetting" reports.</p><h2>4. Use autoexec.cfg for settings that must never reset</h2><p>Because the game rewrites <code>config.cfg</code>, the durable place for your personal cvars is a file the game runs but does not overwrite. Create <code>cstrike/autoexec.cfg</code>:</p><pre>rate 100000 | |
| 17 | +cl_updaterate 101 | |
| 18 | +cl_cmdrate 101 | |
| 19 | +ex_interp 0.01 | |
| 20 | +fps_max 300 | |
| 21 | +net_graph 3 | |
| 22 | +developer 0</pre><p><code>autoexec.cfg</code> is executed automatically at startup and, unlike <code>config.cfg</code>, the engine does not rewrite it on exit — so your values are reapplied every launch no matter what the menu did. This is the standard way to lock in rates and FPS settings.</p><h2>5. userconfig.cfg and per-map configs</h2><p>Some setups also run <code>userconfig.cfg</code> at startup; it works like <code>autoexec.cfg</code> and either is fine — pick one and keep everything in it rather than splitting your settings. You can also run a config on demand from the console:</p><pre>exec myconfig.cfg</pre><p>Any <code>.cfg</code> file in <code>cstrike/</code> can be executed by name, which is handy for switching between, say, a scrim config and a public config.</p><h2>6. Make config.cfg read-only (optional, blunt)</h2><p>If you want the menu to stop clobbering a hand-tuned <code>config.cfg</code>, you can mark it read-only in the file properties. Be warned: this also stops the game saving <em>any</em> future menu changes, so binds you set through Options will not persist. The autoexec approach is cleaner because it layers on top without fighting the game.</p><h2>Common errors</h2><ul><li><strong>Settings reset every launch</strong> — you edited <code>config.cfg</code> with the game open. Close the game first, or move the settings to <code>autoexec.cfg</code>.</li><li><strong>autoexec.cfg ignored</strong> — wrong folder (it must be in <code>cstrike/</code>, not the Half-Life root), or saved as <code>autoexec.cfg.txt</code> with a hidden extension. Turn on file-extension display and check.</li><li><strong>Edited the wrong config.cfg</strong> — you have several game folders (cstrike, czero). Edit the one matching the game you launch.</li><li><strong>Binds vanish but cvars stay</strong> — you set binds in-game after the config ran; save them by binding in <code>autoexec.cfg</code> or letting the game write <code>config.cfg</code> on a clean exit.</li></ul><h2>Verification</h2><p>Put a distinctive line in <code>autoexec.cfg</code>, for example <code>net_graph 3</code>, launch the game, and confirm it took effect. Quit, relaunch, and confirm it is still there — that round-trip proves your settings survive the config rewrite. From there you can safely store your <a href="/tutorials/cs16-best-client-rates">rates</a> and <a href="/tutorials/cs16-fps-boost-guide">FPS settings</a> knowing they will persist.</p> |
do-server-boost-services-work/en.md
A
| @@ -0,0 +1,56 @@ | ||
| 1 | +--- | |
| 2 | +title: "Do CS 1.6 Server Boost Services Work? An Honest Look" | |
| 3 | +excerpt: "Boost services inflate your player count to climb the browser. Here is what they actually do, when it helps, where it backfires, and what genuinely grows a server." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "boosting, growth" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"Server boosting" means artificially raising your displayed player count — usually with bots or fake-player entries — so your server climbs the internet browser, which sorts by population. The pitch is simple and the underlying logic is real: players join servers that look busy, and a server showing 18/24 gets clicks that a server showing 0/24 never will. But whether boosting actually grows a community is a more honest question. This is a straight look at what these services do and when they are worth it.</p> | |
| 10 | + | |
| 11 | +<h2>1. What a boost service actually does</h2> | |
| 12 | +<p>There are two mechanisms, often combined:</p> | |
| 13 | +<ul> | |
| 14 | +<li><strong>Fake players</strong> — a plugin adds phantom slots to the player count the server reports in A2S query replies. No bodies in the game; just a higher number in the browser.</li> | |
| 15 | +<li><strong>Bots</strong> — actual AI players that occupy slots, move, and can be shot. They fill the server visually so a real player who joins is not alone.</li> | |
| 16 | +</ul> | |
| 17 | +<p>Both push your row up the browser's population sort. That is the entire product: visibility through a higher apparent count.</p> | |
| 18 | + | |
| 19 | +<h2>2. Why it can genuinely help</h2> | |
| 20 | +<p>The empty-server problem is real. A new server is invisible at the bottom of a list thousands long, and nobody joins zero. Getting your count off the floor solves a legitimate cold-start problem:</p> | |
| 21 | +<ul> | |
| 22 | +<li>You move up the sort and get seen at all.</li> | |
| 23 | +<li>A joining player sees activity instead of an empty map and is more likely to stay a few rounds.</li> | |
| 24 | +<li>Bots, specifically, give a lone early player someone to shoot, which buys time for a second and third real player to arrive.</li> | |
| 25 | +</ul> | |
| 26 | +<p>Used as a <em>seed</em> during your growth phase, this is a well-worn, effective tactic — most successful small servers did it early. See it in context in <a href="/tutorials/get-players-on-new-server">getting players on a new server</a>.</p> | |
| 27 | + | |
| 28 | +<h2>3. Where it backfires</h2> | |
| 29 | +<ul> | |
| 30 | +<li><strong>Fake players with an empty server disappoint on arrival.</strong> If the browser says 20/24 and a player joins to find themselves alone on the map, they leave immediately and remember your server as a fake. Bots at least deliver something; a pure fake-count does not.</li> | |
| 31 | +<li><strong>It papers over a bad server.</strong> Boosting a laggy, distant, or unremarkable server just buys more people the experience of leaving it. The inflation converts nothing.</li> | |
| 32 | +<li><strong>Regulars notice.</strong> Experienced players can tell bots from humans in a round. If your "population" is 90% bots at peak, your reputation suffers with exactly the people you want to keep.</li> | |
| 33 | +<li><strong>Third-party paid services are a trust risk.</strong> Handing an outside service RCON or installing an unknown plugin to inflate numbers can mean handing over control of your server. Prefer boosting mechanisms you install and understand yourself.</li> | |
| 34 | +</ul> | |
| 35 | + | |
| 36 | +<h2>4. What it does not do</h2> | |
| 37 | +<p>Boosting is not a growth strategy on its own — it is a visibility multiplier. If the thing being made visible is not worth staying for, multiplying its visibility just multiplies the bounce. It also does nothing for retention, ping, or reputation, and no reputable service can promise "real players" — it can only promise a higher number.</p> | |
| 38 | + | |
| 39 | +<h2>5. The honest recommendation</h2> | |
| 40 | +<ul> | |
| 41 | +<li><strong>Do</strong> use bots or a modest fake-count to escape the zero-player trap while you build a real peak-hours crowd.</li> | |
| 42 | +<li><strong>Do</strong> keep the boost proportional — a count that is plausibly reachable by real players, not a permanent fake 32/32.</li> | |
| 43 | +<li><strong>Do</strong> use plugins you control rather than outside services with access to your box.</li> | |
| 44 | +<li><strong>Don't</strong> treat the number as the goal. The goal is real regulars; the number is bait, and bait only works if the trap is worth entering.</li> | |
| 45 | +<li><strong>Don't</strong> boost a server you have not first made worth joining — right mod, close location, good ping, working stats, present admins.</li> | |
| 46 | +</ul> | |
| 47 | + | |
| 48 | +<h2>Common misconceptions</h2> | |
| 49 | +<ul> | |
| 50 | +<li><strong>"Boosting is against the rules and gets me VAC-banned."</strong> No. VAC concerns client cheats; server-side player counts are a server's own business. There is no VAC risk to the server for this.</li> | |
| 51 | +<li><strong>"A high count alone will make the server grow."</strong> Only if the underlying server retains the people it attracts. Numbers without substance churn.</li> | |
| 52 | +<li><strong>"Bots and fake players are the same thing."</strong> They are not — bots occupy real slots and can be played against; fake players are only a number. Bots convert better.</li> | |
| 53 | +</ul> | |
| 54 | + | |
| 55 | +<h2>Verification: is your boost actually working?</h2> | |
| 56 | +<p>Measure real humans, not the total. Use your stats or logs to track <strong>unique real player connections</strong> and <strong>average session length</strong> during boosted hours. If boosting lifts your row and real connections rise week over week, it is doing its job as a seed. If the displayed count is high but real sessions are near zero and short, the boost is masking a retention problem — fix the server (mod, ping, admins, stats) before spending anything on visibility. For the fundamentals a boost is supposed to amplify, start with <a href="/tutorials/pick-a-mod-with-players">picking a mod with players</a> and <a href="/tutorials/choose-vps-for-cs16">choosing the right VPS</a>.</p> |
essential-server-cvars/en.md
A
| @@ -0,0 +1,92 @@ | ||
| 1 | +--- | |
| 2 | +title: "The 25 CS 1.6 Server Cvars You Actually Need" | |
| 3 | +excerpt: "A no-filler reference to the server cvars that matter on a public CS 1.6 server: identity, networking, rates, downloads, logging and security, with sane values." | |
| 4 | +category: "administration" | |
| 5 | +tags: "cvars, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A CS 1.6 server exposes hundreds of cvars, and most are noise you will never touch. This is the short list that actually determines whether your server is findable, plays smoothly, and is safe to run in public. Put these in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>; the round-specific <code>mp_</code> cvars have their own <a href="/tutorials/mp-cvars-reference">reference</a>.</p> | |
| 10 | + | |
| 11 | +<h2>1. Identity and access</h2> | |
| 12 | +<table> | |
| 13 | +<thead><tr><th>Cvar</th><th>Example</th><th>What it does</th></tr></thead> | |
| 14 | +<tbody> | |
| 15 | +<tr><td><code>hostname</code></td><td>"My CS 1.6 Server"</td><td>Name shown in the browser and master list.</td></tr> | |
| 16 | +<tr><td><code>rcon_password</code></td><td>"long-random"</td><td>Remote admin password. Make it long; RCON is brute-forceable.</td></tr> | |
| 17 | +<tr><td><code>sv_password</code></td><td>""</td><td>Join password. Empty = public.</td></tr> | |
| 18 | +<tr><td><code>sv_contact</code></td><td>"[email protected]"</td><td>Contact address in server info.</td></tr> | |
| 19 | +<tr><td><code>sv_region</code></td><td>3</td><td>Master-list region (0 US-East ... 3 Europe ... 255 world).</td></tr> | |
| 20 | +</tbody> | |
| 21 | +</table> | |
| 22 | + | |
| 23 | +<h2>2. Visibility and networking</h2> | |
| 24 | +<table> | |
| 25 | +<thead><tr><th>Cvar</th><th>Example</th><th>What it does</th></tr></thead> | |
| 26 | +<tbody> | |
| 27 | +<tr><td><code>sv_lan</code></td><td>0</td><td><strong>Must be 0</strong> to heartbeat the master list. 1 = LAN only.</td></tr> | |
| 28 | +<tr><td><code>sv_timeout</code></td><td>60</td><td>Seconds before a silent client is dropped.</td></tr> | |
| 29 | +<tr><td><code>sys_ticrate</code></td><td>1000</td><td>Target server FPS ceiling — see <a href="/tutorials/sys-ticrate-truth">the truth about it</a>.</td></tr> | |
| 30 | +<tr><td><code>pausable</code></td><td>0</td><td>Prevent clients pausing the server.</td></tr> | |
| 31 | +</tbody> | |
| 32 | +</table> | |
| 33 | +<p><code>sv_lan 0</code> is the one people forget; with it at 1 the server never appears online and clients hit a LAN error. See <a href="/tutorials/fix-server-not-in-master-list">server not in the master list</a>.</p> | |
| 34 | + | |
| 35 | +<h2>3. Rates — the settings that decide how it feels</h2> | |
| 36 | +<table> | |
| 37 | +<thead><tr><th>Cvar</th><th>Example</th><th>What it does</th></tr></thead> | |
| 38 | +<tbody> | |
| 39 | +<tr><td><code>sv_maxrate</code></td><td>25000</td><td>Max bytes/sec per client. 0 = uncapped; cap it.</td></tr> | |
| 40 | +<tr><td><code>sv_minrate</code></td><td>15000</td><td>Floor so low-rate clients do not choke everyone.</td></tr> | |
| 41 | +<tr><td><code>sv_maxupdaterate</code></td><td>101</td><td>Max snapshots/sec to a client. Cannot exceed server FPS.</td></tr> | |
| 42 | +<tr><td><code>sv_minupdaterate</code></td><td>30</td><td>Floor for update rate.</td></tr> | |
| 43 | +<tr><td><code>sv_maxspeed</code></td><td>320</td><td>Movement speed ceiling. Standard is 320.</td></tr> | |
| 44 | +</tbody> | |
| 45 | +</table> | |
| 46 | +<p><code>sv_maxupdaterate</code> is bounded by your actual server FPS: promising 101 updates on a 60 FPS server is a lie the engine cannot keep, and you get choke on the scoreboard (see <a href="/tutorials/fix-choke-loss-scoreboard">choke and loss</a>).</p> | |
| 47 | + | |
| 48 | +<h2>4. Downloads</h2> | |
| 49 | +<table> | |
| 50 | +<thead><tr><th>Cvar</th><th>Example</th><th>What it does</th></tr></thead> | |
| 51 | +<tbody> | |
| 52 | +<tr><td><code>sv_allowdownload</code></td><td>1</td><td>Let clients download missing content.</td></tr> | |
| 53 | +<tr><td><code>sv_allowupload</code></td><td>1</td><td>Let clients upload their sprays/logos.</td></tr> | |
| 54 | +<tr><td><code>sv_downloadurl</code></td><td>"http://dl.example.com/cs"</td><td>FastDL mirror. See <a href="/tutorials/fastdl-setup-guide">FastDL setup</a>.</td></tr> | |
| 55 | +</tbody> | |
| 56 | +</table> | |
| 57 | + | |
| 58 | +<h2>5. Logging and security</h2> | |
| 59 | +<table> | |
| 60 | +<thead><tr><th>Cvar</th><th>Example</th><th>What it does</th></tr></thead> | |
| 61 | +<tbody> | |
| 62 | +<tr><td><code>log</code></td><td>on</td><td>Enable logging to <code>cstrike/logs/</code>.</td></tr> | |
| 63 | +<tr><td><code>mp_logmessages</code></td><td>1</td><td>Log chat, useful for moderation.</td></tr> | |
| 64 | +<tr><td><code>mp_logdetail</code></td><td>3</td><td>Log attacks and kills (bit 1 + bit 2).</td></tr> | |
| 65 | +<tr><td><code>sv_cheats</code></td><td>0</td><td>Must be 0 in public; 1 enables cheat cvars.</td></tr> | |
| 66 | +<tr><td><code>sv_filterban</code></td><td>1</td><td>1 = banned IDs are blocked (ReHLDS/HLDS ban filter).</td></tr> | |
| 67 | +<tr><td><code>sv_voiceenable</code></td><td>1</td><td>In-game voice on/off.</td></tr> | |
| 68 | +<tr><td><code>decalfrequency</code></td><td>30</td><td>Seconds between spray decals; raise to curb spray spam.</td></tr> | |
| 69 | +</tbody> | |
| 70 | +</table> | |
| 71 | +<p>That is 25 cvars that do real work. On <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> you also get hardening cvars worth adding on top, but the list above is the universal floor.</p> | |
| 72 | + | |
| 73 | +<h2>6. How to think about the groups</h2> | |
| 74 | +<p>Treat these five groups as a checklist for any new server. <strong>Identity</strong> is what players and the master list see, and a weak <code>rcon_password</code> here is the single most dangerous omission — a guessed RCON password hands an attacker the whole server, so make it long and random and never reuse it across servers. <strong>Visibility and networking</strong> decides whether the server is reachable at all; <code>sv_lan 0</code> plus an open UDP 27015 (see <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>) are non-negotiable for a public box.</p> | |
| 75 | +<p>The <strong>rate</strong> group is where most "my server feels laggy" complaints actually live. The rates are a contract between server and client: the server offers a ceiling, the client requests up to it, and the real delivered rate is the minimum of what both allow and what the server FPS can sustain. Set <code>sv_maxrate</code> and <code>sv_maxupdaterate</code> deliberately rather than leaving them at defaults, and keep the update rate within reach of your true server FPS — the details are in <a href="/tutorials/sys-ticrate-truth">the sys_ticrate guide</a>. The <strong>downloads</strong> and <strong>logging/security</strong> groups are the ones people bolt on later and regret not setting from day one: FastDL keeps map changes fast, and logging is the only reason you will be able to answer "who did that?" a week after the fact.</p> | |
| 76 | +<p>A final habit worth forming: comment each block in <code>server.cfg</code> so six months from now you know why a value is what it is. A cvar with no comment is a cvar nobody dares change.</p> | |
| 77 | + | |
| 78 | +<h2>Common errors</h2> | |
| 79 | +<ul> | |
| 80 | +<li><strong>Server invisible online</strong> — <code>sv_lan 1</code>. This is the number-one cause.</li> | |
| 81 | +<li><strong>Choke/loss for everyone</strong> — <code>sv_maxupdaterate</code> promises more than server FPS delivers. Match it to real FPS.</li> | |
| 82 | +<li><strong>Wrong region in the browser</strong> — <code>sv_region</code> set to the wrong number, so region filters hide you.</li> | |
| 83 | +<li><strong>RCON compromised</strong> — a short <code>rcon_password</code>. Use a long random string and consider <code>sv_rcon_*</code> failure limits on ReHLDS.</li> | |
| 84 | +<li><strong>Cvar "does nothing"</strong> — it is being re-set later by <code>amxx.cfg</code> or a per-map config. Trace the execution order.</li> | |
| 85 | +</ul> | |
| 86 | + | |
| 87 | +<h2>Verification</h2> | |
| 88 | +<p>After editing <code>server.cfg</code>, change the map and read values back in the console — typing a cvar name with no argument echoes its current value:</p> | |
| 89 | +<pre>sv_lan | |
| 90 | +sv_maxupdaterate | |
| 91 | +sv_downloadurl</pre> | |
| 92 | +<p>Confirm each shows what you set. Then check the server appears in the internet browser under the right region, and that a client joins without choke. If a value refuses to stick, see <a href="/tutorials/fix-server-cfg-not-executing">why server.cfg is not executing</a>.</p> |
rcon-setup-secure/en.md
A
| @@ -0,0 +1,53 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Set Up RCON and Keep It Secure" | |
| 3 | +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." | |
| 4 | +category: "administration" | |
| 5 | +tags: "rcon, security" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<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> | |
| 10 | + | |
| 11 | +<h2>1. Set a strong rcon_password</h2> | |
| 12 | +<p>Put it in <code>cstrike/server.cfg</code>, not on the command line where it shows up in <code>ps</code>:</p> | |
| 13 | +<pre>rcon_password "9Xf2-qbT!m4Lz7vRpKe0" | |
| 14 | +sv_lan 0</pre> | |
| 15 | +<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> | |
| 16 | + | |
| 17 | +<h2>2. Harden with ReHLDS failure limits</h2> | |
| 18 | +<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> | |
| 19 | +<pre>sv_rcon_minfailures 5 | |
| 20 | +sv_rcon_minfailuretime 30 | |
| 21 | +sv_rcon_maxfailures 10 | |
| 22 | +sv_filterban 1</pre> | |
| 23 | +<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> | |
| 24 | + | |
| 25 | +<h2>3. Protect the file that holds the password</h2> | |
| 26 | +<p><code>server.cfg</code> is plain text. On Linux, lock down its permissions so other users on the box cannot read it:</p> | |
| 27 | +<pre>chmod 600 /home/steam/hlds/cstrike/server.cfg | |
| 28 | +chown steam:steam /home/steam/hlds/cstrike/server.cfg</pre> | |
| 29 | +<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> | |
| 30 | + | |
| 31 | +<h2>4. Do not hand RCON to your admins</h2> | |
| 32 | +<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> | |
| 33 | +<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> | |
| 34 | + | |
| 35 | +<h2>5. Rotate after any exposure</h2> | |
| 36 | +<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> | |
| 37 | +<pre>rcon_password "new-long-random-value"</pre> | |
| 38 | +<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> | |
| 39 | + | |
| 40 | +<h2>Common errors</h2> | |
| 41 | +<ul> | |
| 42 | +<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> | |
| 43 | +<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> | |
| 44 | +<li><strong>Failure-limit cvars rejected as unknown</strong> — you are on stock HLDS, not ReHLDS. Those cvars are ReHLDS-only.</li> | |
| 45 | +<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> | |
| 46 | +<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> | |
| 47 | +</ul> | |
| 48 | + | |
| 49 | +<h2>Verification</h2> | |
| 50 | +<p>From a client console on another machine:</p> | |
| 51 | +<pre>rcon_password "9Xf2-qbT!m4Lz7vRpKe0" | |
| 52 | +rcon status</pre> | |
| 53 | +<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> | |
| 0 | 54 |
