In my article on screen sharing, I demonstrated how to use VNC to view and control remote desktops. Sometimes, a full remote desktop viewer isn't always practical. But you still have options available if you need to control or view things on someone else's screen.
OpenSSH isn't really meant to share a screen, but it can perform some similar tasks. For instance, if a user you're supporting needs support with a GUI application, you can use an SSH connection with X-forwarding to launch an instance of that application, modify its settings, or test something they claim is not working correctly.
The difference is that you're not actually sharing the screen. VNC connects to a desktop session, but SSH spawns exactly one application: a shell. From this shell, you can execute any command available to the system you connected to, even launch GUI applications.
To connect to a remote machine over SSH, you must ensure that the remote computer is: accessible through firewalls, and that it is accepting SSH connections. If either of these two prerequisites are not satisfied, then you can't open a remote shell. Need to know more about firewalls in Linux? Consider this introduction to firewall-cmd.
To allow incoming SSH connection requests, the remote computer (the one you're targeting for access) must be running an SSH server. Most Linux and MacOS computers already are, but they may be inactive by default, so you must have your user activate it. In the GNOME desktop, remote login is activated in the Settings application, in the Sharing category:
Once activated, you can log in. Normally, you would forward a remote computer's X11 graphical display to your local computer with the -X option, but the OpenSSH application places additional security limits on such connections as a precaution. As long as you're starting a shell on a trusted machine, you can use the -Y option to opt out of the excess security:
$ ssh -Y 18.104.22.168
Now you can launch an instance of any one of the remote computer's applications, but have it appear on your screen. For instance, try launching the Nautilus file manager:
remote$ nautilus &
The result is a Nautilus file manager window on your screen, displaying files on the remote computer. Your user can't see the window you're seeing, but at least you have graphical access to what they are using. Through this, you can debug, modify settings, or perform actions that are otherwise unavailable through a normal text-based SSH session.
Keep in mind, though, that a forwarded X11 session does not bring the whole remote session to you. You don't have access to the target computer's audio playback, for example, though you can make the remote system play audio through its speakers. You also can't access any custom application themes on the target computer, and so on (at least, not without some skillful redirection of environment variables).
However, if you only need to view files or use an application that you don't have access to locally, forwarding X can be invaluable.
Tmux is a screen multiplexer, meaning that it provides your terminal with virtual terminals, allowing you to switch from one virtual session to another. Modern terminal emulators feature a tabbed UI, making the use of Tmux seem redundant, but Tmux has a few peculiar features that still prove difficult to match without it.
First of all, you can launch Tmux on a remote machine, start a process running, detach from Tmux, and then log out. In a normal terminal, logging out would end the processes you started. Since those processes were started in Tmux, they persist even after you leave.
Secondly, Tmux can "mirror" its session on multiple screens. If two users log into the same Tmux session, then they both see the same output on their screens in real time.
Tmux is a lightweight, simple, and effective solution in cases where you're training someone remotely, debugging a command that isn't working for them, reviewing text, monitoring services or processes, or just avoiding the ten minutes it sometimes takes to read commands aloud over a phone clearly enough that your user is able to accurately type them.
To try this option out, you must have two computers. Assume one computer is owned by Alice, and the other by Bob. Alice remotely logs into Bob's PC and launches a Tmux session:
alice$ ssh bob.local alice$ tmux
On his PC, Bob starts Tmux, attaching to the same session:
bob$ tmux attach
When Alice types, Bob sees what she is typing, and when Bob types, Alice sees what he's typing.
It's a simple but effective trick that enables interactive live sessions between computer users, but it is entirely text-based.
With these two applications, you have access to some powerful methods of supporting users. You can use these tools to manage systems remotely, as training tools, or as support tools, and in every case, it sure beats wandering around the office looking for somebody's desk. Get familiar with SSH and Tmux, and start using them today.