Can one access an open terminal on the computer via SSH?

Question

I'm looking to access an open terminal, that is, opened locally on my machine, from a remote computer without using tmux or screen. There's a few reasons for this, the simplest of which is that I keep landing up with a situation where I didn't plan ahead, run something big on my pc at work, go home and then want to check on it via ssh.

In essence I'm looking for a way to attach to the terminal already running on a computer and view its output.

Now, I know that there are a few threads out there that say you can't do this (such as this one ), and others that simply recommend screen and tmux (like this one, this one or this one). What I'm looking for is a way to directly access a running terminal process, or at the very least see the cached output of that terminal. I don't necessarily need to be able to enter commands in that terminal.

Is there a way to do this? Otherwise, any ideas on a hack that could work? I was thinking I could probably find a way to automatically log stdout, stderr and the commands to a file (perhaps a clever tweak on bash history that logs everything?)

score 5 · Answer 1 · answered Jul 27 '17 at 23:39

Simply due to how terminals are built, it is not possible to access everything, i.e. you cannot view a running terminal and interact with it if you don't have a detachable session running within the said terminal, such as screen or tmux session, or if you haven't started that command with logging via script command.

What can be done is partially view TTY via sudo cat /dev/vcs1 command. /dev/vcs[1-6] correspond to their respective TTY consoles. This is limited by the scrollback buffer size of the respective TTY, which means you can only see whatever is held in memory up to certain number of lines. This of course can be tuned to increase the number of lines as shown in muru's answer here. Alternatively, you probably should try

setterm -file log.txt -dump [ttynumbers]

which was mentioned in this ssh question.

At the end of the day, bodhi.zazen properly noted in their comment, that your refusal to use screen or tmux is the biggest problem. I totally understand, I often forget to track long-running programs myself, but with some commands you should start thinking ahead.

score 2 · Answer 2 · answered Jul 28 '17 at 03:16

Since you have tagged this gnome-terminal, depending on the version, it might be possible to view part of the output. From this blog post, where the author wanted to see what GNOME Terminal does for "unlimited" scrollback:

I could just look at what files gnome-terminal had open, so lsof to the rescue. Then I found it was being sneaky, it had a number of files called /tmp/vteXYZ1tv open, but it had already deleted them. Thus you can't see them when browsing, and they will be removed when the program closes. [...] They can be restored though, my way (there are probably others), was to do a ls -l /proc/<gnome-terminal pid>/fd to see what they point to. Then you can cat these to make a new file. These are just a verbatim copy of the terminal output. No compression. No nothing.

But in newer versions, the files are supposed to be encrypted. From this answer:

vte-0.40 (which will most likely appear in Ubuntu 15.10 W.W.) will compress and encrypt these files. This will shrink the required storage to approx third–fourth of its size (if your app produces X amount of data as plain text, somewhere between X/4 .. X/3 is a reasonable estimate for the storage that'll be required), and also gets rid of the privacy/security issue in case someone gets raw access to the hard drive.

If you only want future output, you could try dragging the process to a new TTY using reptyr.

score 1 · Answer 3 · answered Oct 26 '17 at 10:36

Depending on the process running inside the terminal, you might have success by peeking into the state and the actions made by that process rather than what it has displayed in the terminal.

A few examples, assuming you've somehow figured out the PID (process ID) of the given process (e.g. using pidof or ps):

If the given tool launches subcommands one by one, check which one is running using ps.
If the given tool sometimes changes its working directory, check that at /proc/<PID>/cwd.
If the given tool operates on many files in a row, check which one's open under /proc/<PID>/fd. If you can't see any at the moment, it might be that your process has just closed one and is about to open the next; check again a few times for the contents of that directory.
If the command operates on a single huge file using the standard read/write syscalls, you can find the file descriptor number under /proc/<PID>/fd and check for the current offset in the corresponding file under /proc/<PID>/fdinfo. If the command uses pread/pwrite instead then see the next bullet point.
You can connect to the process using strace to see what it's doing: strace -p <PID>. Quit shortly afterwards using Ctrl+C (it terminates strace only, not the application you're tracing). Examine the output and look for relevant stuff that might give you an idea. Use for example the -e trace option to restrict this output to file operations only. You'll see e.g. the filenames that are being opened by your applications, as well as the offsets where pread/pwrite operations happen.

score 0 · Answer 4 · answered Jul 28 '17 at 19:35

From the comments, there are several potential solutions, but they all have to be implemented BEFORE you run the command in the graphical terminal.

For example, see https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1356433

So users within the same X session can not reconnect to closed tabs.

You can try reptyr as suggested by muru, and this is a cool solution, but better to plan your ssh sessions better from the start.

You need to develop a better working strategy.

Use screen or tmux or similar. These tools were designed for exactly this scenario.

Personally I use screen as I am familiar with it and for the reasons you state I always use a screen session over ssh, ie I start screen and verver really exit the screen session. Often I have more then one screen session, one for each VM on a host for example.

Use a VNC server. You can run the session over ssh (VNC-over-SSH) or use FreeNX which is faster and more secure. DO NOT RUN A VNC SERVER OVER "THE INTERNET" WITHOUT SSH OR FREENX

VNC over ssh - https://www.cyberciti.biz/tips/tunneling-vnc-connections-over-ssh-howto.html

FreeNX - https://www.howtoforge.com/tutorial/freenx-ubuntu-14-04-trusty-tahr/