1

How can I run a program that expects to be executing in a terminal in such a way that it's STDIO can be arbitrarily connected-to remotely?

Specifically, I want to be able to launch gdb on one host and connect into it's terminal interface remotely, such that I can pause execution with CTRL+C, change the layout (e.g. layout regs), etc. The diagram below illustrates what I'm trying to accomplish.

Connecting to GDB client remotely

So far, the closest I've gotten is to use socat on the remote host to create the pty and start gdb:

$ socat PTY,link=$HOME/somedev,rawer, SYSTEM:"gdb 2>&1",pty

Then pipe that PTY to/from a netcat listener:

$ cat ~/somedev | nc -l 5556 > ~/somedev

And on the workstation, start netcat:

$ nc <remote_host> 5556

What I have at this point is close to what I want, but the terminal interaction is a bit wonky (e.g., if I change gdb's layout, it looks okay at first, but new lines coming in mess up alignment of the windows, etc.), and CTRL+C does not get forwarded through to the gdb process to suspend the process.

I admit, some of this behavior is probably due to limitations with netcat - I'm open to other programs to make the connection to the tcp listener on the remote host.

Some other constraints for a solution:

  • The gdb process must begin independently of a remote connection being established (in other words, I can't use socat to start the gdb process, as in socat TCP-LISTEN:5556,reuseaddr,fork EXEC:"gdb"). This also eliminates solutions that involve running gdb on the workstation rather than the remote host.
  • CTRL+C entered on the workstation terminal must cause SIGINT to be sent to the gdb process.
Improve this question

1 Answer 1

Reset to default
1

The standard solution to connect to a remote host is SSH and I don't see anything in your question that rules it out. Terminal forwarding is a built-in feature of SSH.

The gdb process must begin independently of a remote connection being established

For that, start it inside a screen or tmux session. Then use SSH to connect to that session.

Netcat only forwards data. The interface of a terminal includes more than the data exchanged over the terminal: it also requires handling ioctl calls, otherwise certain features don't work, like allowing the application to query the terminal's size, as well as input translation such as translating Ctrl+C to a SIGINT signal. Socat can do it if you call it right, but it's a lot easier with SSH.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.