You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Embed websockify in GoTTY. It needs to be explicitly enabled when launching GoTTY for security reasons.
Add an escape sequence to tell the webtty that e.g. a vnc or spice server is available. E.g. "]9876;spice://10.20.30.40:5442;credentials".
The webtty can then connect GoTTY's websockify path, send "10.20.30.40:5442" as the target IP:port and GoTTY will connect it.
Once the connection is established, it can be passed along to a js spice client.
This may or may not be a security concern. Let's look at three scenarios:
For the common use case where you run e.g. "gotty -w bash", the user lands in a bash prompt where they can just netcat their way to any other system. Giving them access via websocket to that same network should not be a concern.
If you're using gotty to just show something, e.g. "gotty top", the user can't even interact with top, but only see its output. In that case, giving them free reign to connect to arbitrary systems on the server network is obviously terrible.
If you're doing e.g. "gotty -w login -", you'll be presented with a login prompt. In other words, the authentication step is outside of GoTTY's control.
If we only had to worry about scenarios 1 and 2, we could simply use the "-w" flag to decide whether to allow this websockify mechanism. Because of scenario 3, it needs to be a separate flag. It should restrict the access to specific hosts/ports.
The text was updated successfully, but these errors were encountered:
Use case: Suppose I want to launch a GUI from the tty I'm connected to. There are excellent SPiCE clients (e.g. https://github.com/eyeos/spice-web-client) that we can use.
We need a few things to make this work well:
This may or may not be a security concern. Let's look at three scenarios:
If we only had to worry about scenarios 1 and 2, we could simply use the "-w" flag to decide whether to allow this websockify mechanism. Because of scenario 3, it needs to be a separate flag. It should restrict the access to specific hosts/ports.
The text was updated successfully, but these errors were encountered: