I'm designing a large online puzzle and would like one section to have players connect with an SSH client such as PuTTY to uncover lore or progress the game. The connection would lead to a text-adventure-style interface rather than a real shell, with only a few emulated commands such as cd, ls, cat, and possibly ssh. The displayed files and directories would be virtual, and players would receive a game-specific username and password.
I don't want participants—or automated attackers—to gain access to the host system, execute arbitrary commands, or damage anything. Is it practical to run a program that speaks the SSH protocol and emulates a terminal safely? Are there existing libraries for this, or would I need to implement the server myself? I'm open to using Go, Rust, or another suitable language, and I'd also consider a simpler protocol if SSH is unnecessary.
3 Answers
Another option is a normal SSH server configured with a dedicated account whose login shell is your text-adventure program. That can work, but it requires careful configuration, and accidentally exposing a real shell or an unrestricted command such as ssh can create a serious escape route. Don’t rely on obscurity, deleting documentation, or a username and password to protect it—public SSH services attract constant automated probing. Test the application in an isolated container or disposable virtual machine, give it no useful privileges, restrict outbound access, and monitor and rebuild it regularly.
Yes, an embedded SSH server can handle this. Libraries such as gliderlabs/ssh for Go let you authenticate users and provide your own session handler instead of launching a system shell. The safest design is to implement the allowed commands directly in your program, never pass player input to a shell, avoid accessing real files, and run the service as an unprivileged account in a separate, tightly restricted environment. Even then, keep the host and network permissions minimal and treat all input as hostile.
That’s exactly the kind of interface I had in mind. I’ll look into implementing it in Go or Rust rather than exposing a normal shell.
If you don’t specifically need SSH encryption or SSH key authentication, a plain TCP or Telnet-style service may be much simpler. Your program can accept a connection, display prompts, and interpret a small command set without involving a real terminal or filesystem. The tradeoff is that Telnet is unencrypted, so passwords and puzzle content can be observed in transit. For a public game, a custom TLS-wrapped protocol or HTTPS/WebSocket interface may be a better modern alternative.
The intended interface is only an emulation, not access to the host filesystem. I’ll avoid exposing a real shell and will investigate isolation before putting anything online.