SteamCMD login and Steam Guard: anonymous vs account

Most dedicated servers install with +login anonymous and need nothing from you. A handful - DayZ and Arma 3 are the ones you will meet first - refuse an anonymous session, and SteamCMD then wants a real Steam username and password, answers a Steam Guard challenge once, and caches a login token so later updates run unattended. That token, and the password you typed to get it, end up on the server. So the whole security story fits in one sentence: use a spare Steam account that owns the game and nothing else, and treat the machine that runs SteamCMD as somewhere that account's credentials now live.

The rest of this post is the detail: which servers need an account, what each Steam Guard prompt looks like and how to answer it, where the cached credential is stored and how long it lasts, how to set up the spare account properly, and what the login errors mean. The basics of SteamCMD itself - install, force_install_dir, validate, scripts - are in SteamCMD explained, and this post does not repeat them.

What the login actually decides#

SteamCMD always logs in before it downloads anything. The login is not about the server you are going to run - a game server never uses this session once it is running. It decides one thing: which licences the download session holds.

• Anonymous is a session with no account behind it. It holds a licence for every app the publisher has marked as free for anonymous download, which covers most dedicated-server tools. No password, no Steam Guard, nothing stored.
• An account login holds whatever that account owns, plus the free tools. It is needed when the publisher has restricted the server tool, or its Workshop content, to accounts that own the game.

Two consequences follow, and both surprise people. First, the credential is only needed at install and update time. The running DayZ or Arma 3 server does not log in to Steam with your account; it is SteamCMD, run before the server starts, that does. Second, the credential is needed again on every update, which is why it is cached rather than typed once and forgotten. A server that updates on every restart is a server that logs in to Steam with that account every restart.

The login is also a separate thing from a game server login token. A GSLT is what a running server presents so that Steam lists it in the browser; it is created on a web page and is never typed into SteamCMD. People mix the two up because both are "a Steam credential the host asks for", but one installs the files and the other identifies the running server. A few games need both.

Which servers need a real account#

There is no flag you can read in advance that says "this one refuses anonymous". You find out from the publisher's documentation, from the Valve developer wiki's dedicated servers list, or from SteamCMD itself, which answers an anonymous attempt on a restricted app with No subscription.

DayZ is the clear case. The DayZ Server tool (app 223350) will not install for an anonymous session or for an account that does not own the game, and its Workshop items are fetched against the game's app id, 221100, which needs the same owning account. DayZ server and mods covers the rest of that install.

Arma 3 is the case where sources disagree in an instructive way. Valve's list marks the server tool (233780) as not available anonymously, and Bohemia's own server documentation tells you to log in with a real username and suggests a separate account for the job. Bohemia also describes the server package as free, so whether the account has to own Arma 3 just to fetch the server has varied by time and by who you ask. Workshop mods are a different matter: workshop_download_item 107410 <id> needs an account that owns Arma 3. Since nearly every real Arma 3 server runs mods, plan on an owning account either way. Arma 3 server and mods has the full mod workflow.

Project Zomboid and 7 Days to Die are the grey zone. Their server tools have been widely installed with login anonymous for years, yet hosts and guides differ on whether a login is wanted, and publishers can change an app's access without announcement. The practical test is quick: try anonymous first. If it installs, you need no account for the server itself. If you get No subscription, you do. SteamCMD app IDs and beta branches has the server and game ids for thirty titles if you are unsure which number to test.

Logging in for the first time#

The first login with an account should always be interactive - you, at a terminal, able to read what SteamCMD asks. Start SteamCMD with no arguments and log in at its prompt, so the password never appears on a command line:

$ ./steamcmd.shSteam> login myserveraccountpassword:

What happens next depends on how Steam Guard is set up on the account, covered in the next section. Once the login succeeds you will see a line confirming it and the Steam> prompt returns. From there, install as normal:

Steam> force_install_dir /srv/dayzSteam> app_update 223350 validateSteam> quit

That one interactive session does two jobs: it satisfies Steam Guard, and it leaves a cached credential behind. Every later run - a cron job, a restart script, a panel update - can then log in with the username alone:

$ ./steamcmd.sh +force_install_dir /srv/dayz \    +login myserveraccount \    +app_update 223350 +quit

No password, no code. SteamCMD finds the cached credential for that username and uses it. If it cannot find one, it says so and either prompts (in an interactive run) or fails (in a script with @NoPromptForPassword 1), which is exactly what you want from an unattended job: a loud failure rather than a hang.

Avoid the shortcut of +login user password on the command line. It works, but the password lands in your shell history, in the output of ps for anyone else on the machine while SteamCMD runs, and often in whatever logs the job's output. In a container it is worse: a password passed as an environment variable is readable by anyone who can inspect the container. Environment variables and secrets covers why that is a weaker hiding place than people assume.

Steam Guard: email codes, mobile codes and approvals#

Steam Guard is Steam's second factor, and SteamCMD meets it the same way the desktop client does when it signs in from a new device. There are three states an account can be in, and each produces a different experience.

Email Steam Guard

The account has Steam Guard but no mobile authenticator. On the first login from a new machine, Steam emails a short code to the account's address, and SteamCMD asks for it:

Steam Guard code:

Type the code from the email. The code is tied to that login attempt, so request it and use it in one go; an old code from an earlier attempt is rejected. If the email never arrives, check the spam folder before retrying - repeated attempts are how you end up rate-limited.

Mobile authenticator

The account has the Steam Mobile app set up as its authenticator. SteamCMD asks for the rotating code from the app:

Two-factor code:

The code is five characters and changes every 30 seconds. Type it promptly; a code that rolled over while you were typing produces a mismatch, and you simply try again with the new one. Recent Steam builds can also offer approval on the phone instead of a typed code, the way the desktop client does - if SteamCMD tells you to confirm the sign-in in the app, do that and it continues. Whether you see the prompt or the approval depends on the SteamCMD build, so read what it prints rather than assuming.

SteamCMD also accepts the code as a third argument to login (login user password code), which is how people answer Steam Guard from a script. It works, but it puts the password on the command line, so use it only for a one-off from a terminal you control, never in a file.

Steam Guard turned off

No prompt at all. This is the setup people reach for after the first frustrating Steam Guard loop, and it is the wrong fix. An account with Steam Guard off is protected by its password alone, and the password is precisely the thing you have just typed into a server. Leave Steam Guard on; it only asks once per machine.

Cached credentials: where they live and when they stop working#

After a successful login SteamCMD stores a login token for that account in its configuration, in config/config.vdf under SteamCMD's data directory. On Windows that is the config folder beside steamcmd.exe. On Linux it depends on how SteamCMD was installed: the Valve tarball and the distribution packages keep their data in different places, commonly under ~/Steam or ~/.steam. If you are not sure, search the SteamCMD user's home directory for config.vdf. Older builds also left ssfn sentry files beside it, which played the same role.

What matters about that file:

• It is a credential. It is not your password, but it lets SteamCMD on that machine log in as the account without one. Anyone who can copy it can, in practice, do the same - which is why it belongs to a spare account and nowhere else.
• It belongs to the user that ran SteamCMD. Run the first interactive login as the same Unix user that the cron job or service uses. Logging in as yourself and then running updates as a steam service user is the most common reason a cached login "does not work".
• In a container it must persist. If SteamCMD runs inside a container whose filesystem is thrown away on restart, the cached credential goes with it, and every start asks for Steam Guard again. Put SteamCMD's config directory on a persistent volume.

The cache does not last for ever. It stops working when:

1. The password changes. Steam ends existing sessions, and SteamCMD needs the new password and, usually, a fresh Steam Guard challenge.
2. You deauthorise devices. "Deauthorize all other devices" on the account's Steam Guard page logs out every machine that holds a cached login, SteamCMD included. That is also the right move if a server holding the credential may have been compromised.
3. The token simply expires. Cached logins are long-lived but not permanent. When one lapses, the next unattended update fails at the login step.

That third case is the one that bites in production, because it happens at a random time months after setup. An unattended update must therefore be able to fail safely: check for the Success! App 'X' fully installed. line rather than trusting the exit code, and start the server on the existing files if the update did not happen. Automating game server updates covers wrapping SteamCMD so that a failed login means a stale server rather than a dead one.

Setting up the spare account#

A spare account is not a nice-to-have here. The password and a long-lived login token sit on a machine that, for a rented server, someone else administers, and that runs mods and plugins written by strangers. If that account is also the one with your library, wallet balance, saved payment cards and fifteen years of friends, all of that is one leak away.

Setting one up properly:

1. Create a new Steam account with its own email address - a mailbox you use for nothing else. If the email is shared with your main account, compromising the mailbox compromises both.
2. Buy or gift the game to it if the server needs an owning account (DayZ, and Arma 3 for Workshop). This costs one copy of the game, and it is the price of keeping your main account off the server.
3. Do not add a payment method and do not top up a wallet. Nothing on this account should be spendable.
4. Turn on Steam Guard. Email Steam Guard on the dedicated mailbox is fine; the mobile authenticator is stronger. The Steam Mobile app can hold more than one account, so the spare one can live beside your main account on the same phone.
5. Give it a unique, generated password from a password manager. It will be typed into a server, so assume it may be seen, and make sure it opens nothing else.
6. Do not play on it. The account exists to download files. Keeping it out of play keeps it out of trades, friend requests and the phishing that follows them.

A spare account also helps with Workshop downloads for heavily modded servers, because Workshop subscriptions and downloads attach to that account rather than to your personal one. The download mechanics, including what happens when an item is removed from the Workshop, are in Steam Workshop mods on dedicated servers.

The security risks, stated plainly#

Typing a Steam login into a server is a trust decision, and it helps to be specific about who can see it afterwards.

The host line deserves the most honesty. Any host that runs SteamCMD on your behalf for a game that needs a login has to hold your credentials in a form it can use, which means it can read them. There is no clever arrangement that avoids this. What differs between hosts is whether they say so. On RE:NODE the games that need your own Steam login - Arma 3, DayZ, Project Zomboid and 7 Days to Die - are created as soon as payment clears, and the install waits on the Setup tab until you enter the credentials there. They are stored as you typed them, and that is the reason this whole post keeps returning to the spare account.

The other lines are the ones you control:

• File access is credential access. A subuser who can browse the server's files may be able to read the cached login. Give staff console access without file access where they do not need files - subusers and least privilege shows how to build roles like that.
• Mods run with the server's permissions. A plugin can read anything the server process can. Malicious plugins and mods covers what that looks like in practice.
• Support conversations leak. Never paste a password or a Steam Guard code into Discord, a forum or a public channel while asking for help. On RE:NODE a support ticket takes private attachments, which is the right place for anything sensitive.
• Your panel account is the front door. Whoever can sign in to the panel can see the Setup tab. Turn on two-factor on your panel account so the Steam login is not one leaked panel password away.

If you think the spare account's credentials have been exposed, the response takes five minutes: change the password, use "Deauthorize all other devices", and log in once by hand on the servers that should still have access. Because the account holds nothing but a game licence, that is the full extent of the damage.

Login errors and what they mean#

SteamCMD reports login failures on the line that starts Logging in user, with the reason in brackets at the end.

Rate Limit Exceeded is the one to respect. It is triggered by repeated failed logins, typically a script retrying in a loop with a stale password, and every further attempt extends the lockout. Stop whatever is retrying, wait - often an hour or more - and then log in once, by hand, correctly.

No subscription after a successful login is never a password problem. Either the account does not own the game, or you passed an app id that belongs to something else. For DayZ, confirm the account owns DayZ itself; for an Arma 3 Workshop download, confirm it owns Arma 3 and that you used 107410, not the server's 233780.

A login that works by hand and fails from cron is almost always the user mismatch described above: the cached credential belongs to whichever user ran the interactive login, and the scheduled job is someone else.

FAQ#

Can I install a DayZ server without owning DayZ?

No. The DayZ server tool refuses anonymous logins and accounts that do not own the game, and its Workshop mods need the same owning account. Buy a copy on a spare account rather than putting your main account on the server.

Do I have to enter a Steam Guard code every time the server updates?

No. Steam Guard is answered once per machine. SteamCMD then caches a login token and later runs log in with the username alone. You will be asked again only after a password change, a device deauthorisation, or when the cached login eventually expires.

Is it safe to give a host my Steam login?

It is as safe as the host, which is why you should only ever give one a spare account. Any host that installs DayZ or Arma 3 for you has to store a usable credential. Choose a host that tells you so, and make sure the account behind it owns nothing you would miss.

Should I disable Steam Guard on the spare account to stop the prompts?

No. The prompt only appears on the first login from each machine, so disabling Steam Guard saves you one code and removes the only protection left once the password has been typed into a server. Keep it on, ideally with the mobile authenticator.

Does the running server use my Steam account?

No. The account is used by SteamCMD to download and update files. The running server does not log in with it. If the game also needs a server listing token, that is a separate credential created on Steam's game server account page.

How do I make a machine forget the login?

Delete the cached credential from SteamCMD's config/config.vdf, or, if you do not control the machine any more, use "Deauthorize all other devices" in the account's Steam Guard settings and change the password. Either way the next login on that machine needs the password and Steam Guard again.