Hi everyone, first time posting in a Linux support forum with a problem I don't know if anyone will have an answer to, so, bear with me please. I'm also not sure if I should be posting this here, but, again.. first time.

I'm running CentOS 6.5 intended to be a game server machine. The game in question is Team Fortress 2.

Now, the issue is one that I can't for the life of me figure out. Basically, the game server itself seems to run fine. It reads custom executable files whilst running (which tells me it isn't a permissions issue), and if I execute commands through the in-game remote console, commands are indeed executed. However, when I execute the same commands via SSH, it draws a blank. A friend said it isn't accepting stdin?

The last four lines there were manually input. If I were to type the same status command with the remote console in game, it would correctly return:

Basically the commands aren't making it to the server when executed by SSH.

Any ideas, or perhaps anything else I can display?

Your game server is running on a linux platform (CentOS 6.5) so it's OK to post questions here.
While that's probably not a big deal when you're accessing the server from the console, it is probably not acceptable when accessing it remotely (ssh), did you make an administrative account for the server? Your system account is apparently not logging you in as the servers admin (or that line would show you as logged it).

I'm fairly sure that account login thing isn't actually on the side of Linux, but for a separate authentication method used by the game to add it to a public matchmaking queue.

As far as the question, I've tried it on both its own administrative user and on root.

Have you ever logged in locally (i.e. from the console) as the administrative user of the game server and tried the same commands?
Have you ever logged into the server and run something innocuous (like "ls -l" in your home directory) to see if the server is "accepting stdin"?
What have you done to trouble shoot this problem before posting this question?

I don't understand the first question as it seems to be the exact problem in the thread.

As far as troubleshooting. I've tried the server instances with and without an instance of screen, ruling out screen as an interference. I've tried running it from different users other than root (which I shouldn't have to do.) Not quite sure what else could be problematic.
As far as the "ls -l" test, yep. That works.. The server itself responds perfectly, it simply doesn't allow the issuing of commands it normally would when attached to the game server/script instance. However, it still allows commands that aren't related to the game, like ctrl+a+d to detach from the screen.

Normally when I get a dedicated server to configure, I'll set up Steamcmd, vsftpd, etc. I'll get all my files together, start/update scripts for the server instances. I'll run them all on their own individual screens. However, out of perhaps 8 dedicated servers, this is the first one that has given me this particular error.

Think of it this way bloop. When you as the linux administrator sit at your terminal without being logged into the game server, it works fine.
When you remotely access the game server (ssh), the game server is unresponsive. The remote account works (the ls -l demonstrates it has basic functionality). So what could be wrong?
The games server apparently has it's own accounts, your not logging into one of them when accessing locally, perhaps you need to do that if you're accessing remotely. That would make sense, otherwise why would the game server have an administrative user access control system at all (which it apparently does).

Welp, problem solved.

To anyone else that might be reading this and having this issue, I guess maybe the srcds_linux script may have been updated or something and requires new libraries.

Thanks for the help though!