Ttyd

Continuing from previous post, this post is about how to handle ttyd using golang. Overview The golang handler consists of 3 parts: sending frontend, sending auth token and handling websocket connection. Sending Frontend Golang can embed static assets in the compiled binary so there is no need to specify a path to the file. The frontend can be extracted using devtools. //go:embed ttyd.html var ttydHtml string func index(writer http.ResponseWriter, request *http.Request) { _, _ = io.WriteString(writer, ttydHtml) } Sending Auth Token We just write a static json string with an empty token since we don’t check the token in our implementation. ...

Previously I have written a post about ttyd that describes how to authenticate requests for ttyd sessions. The problem is that vanilla ttyd only supports running a predefined command, and it’s nearly impossible to customize what command to run based on the authenticated user. To solve this problem we need to port ttyd to another language. But first we need to understand how ttyd works. Request Waterfall When a browser connects to a ttyd instance, below is the order in which resources are requested. ...

Background ttyd is a simple tool for sharing terminal over the web. It can be used in place of ssh clients to manage remote servers as it only requires the presence of a browser with internet connectivity. It can be used with a variety of commands ranging from showing the output of top command to fully interactive bash session. However, ttyd itself only supports basic auth and auth proxy. In basic auth mode, ttyd authenticates requests from a predefined list of users. In auth proxy mode, ttyd will only authenticate clients with the specific http header. The first mode has the problem that users cannot be updated while ttyd is running. ttyd must be stopped and rerun with another set of users if users are to be updated. The second mode assumes ttyd is behind a reverse proxy and delegates authentication to the reverse proxy. If I’m using a reverse proxy to authenticate the request, then why check the header anyway? ...