Using ssh and screen To Create Persistent Terminal Sessions Accessible From Almost Anywhere
Many users like to use VNC for managing tasks that require a persistent desktop on a remote Linux or Solaris machine, but for some tasks where persistence is required, a complete desktop can often be overkill. Especially if what one is working on is CPU or memory sensitive, and the tasks being done can easily be handled via a terminal (command-line) session on the machine.
Persistence, for our purposes here, is defined simply as being able to disconnect from a desktop or terminal without the tasks running in it being halted, and then being able to reconnect at some later time, or even from some other machine to continue the running session. VNC and Remote Desktop are examples of techniques for creating persistence sessions of a whole desktop. With ssh and screen, one can create a persistent environment for terminal (command-line) sessions in *nix or Cygwin environments.
Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a standard VT100 terminal.
When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill existing windows, view a list of windows, turn output logging on and off, copy-and-paste text between windows, view the scrollback history, switch between windows in whatever manner you wish, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the user’s terminal. When a program terminates, screen (per default) kills the window that contained it. If this window was in the foreground, the display switches to the previous window; if none are left, screen exits.
Everything you type is sent to the program running in the current window. The only exception to this is the one keystroke that is used to initiate a command to the window manager. By default, each command begins with a control-a (abbreviated C-a from now on), and is followed by one other keystroke. The command character and all the key bindings can be fully customized to be anything you like, though they are always two characters in length.
For more information on screen, including default key bindings and usage flags, see the screen man page for your distribution.
ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin, rsh, and telnet, and provide secure encrypted communications between two untrusted hosts over an insecure network.
For more information on ssh, including usage flags, see the ssh man page for your distribution.
A Simple Example
Nothing explains better than a real-world example of the tools in use.
I sometimes have the need to compile a kernel, update software, or run long batch processes on my own Linux box, or other *nix boxes in the enterprise. To do so locally, I would simply open an xterm and run the necessary commands to kick the process off. I could then watch the process to completion in my open xterm window, or come back after some time and view the output in the xterm window for any errors. That works, but makes it inconvenient if I find myself working on another machine somewhere else, or worse, I have left for the day. In both cases, I have to wait until I’m back at my desk to check on the progress and correct any errors that popped-up. No fun. Here’s what I do instead:
Start Screen Session
On my machine, I open an xterm, start a screen session, and name it “kernel” so I can identify it by what it will be doing.
screen -S kernel
This appears identical to my previous xterm window, except if I open up another xtem and type:
I get output that looks like:
There are screens on: 4222.kernel (Attached) 13423.guinness (Attached) 13483.harp (Attached) 3 Sockets in /var/run/screen/user.
(The guinness and harp sessions had been previously opened for work to be done on those two machines.)
Begin Work in Screen Session
Still on my machine, I can kick off my kernel compile in my newly opened “kernel” screen session.
Connect From Remote Machine
Once at home, I can connect to the VPN and ssh to my machine.
Attach to Screen Sessions From Remote Machine
In the ssh shell on my machine, I can reconnect to the session by name in one of two ways:
1. By forceably detaching the screen session running in my xterm back at the office, and reattaching to it on my remote machine.
screen -D -R kernel
2. By connecting to the session in multi mode, leaving the instance on the xterm back at the office still attached (sharing the terminal between two or more machines — my personal favorite).
screen -x kernel
Work can then be done as if back on the original terminal you began on for the task.
Detach Screen Session From Remote Machine
From within the screen window, you can detach from a screen session using the Control-a command mechanism:
This detaches the session only from the local box (if the session was also attached on another machine), and will bring you back to your ssh shell.
If you were done with the screen session, you could exit the shell running within it instead of using C-a d, which would also exit that running instance of screen (closing it on all machines), bringing you back to your ssh shell.
From there you can exit to close out the SSH connection.
Reading through this, it may seem this is all far more trouble than it’s worth. Believe me, it only seems that way at first glance. Once or twice through the process, you may find screen and ssh to be indispensible tools in your daily arsenal. Remember, any command that can be run in an interactive shell can become portable, and even shared with others by way of screen (see the screen man page for configuration for multi-user, shared sessions with or without passwords).
I tend to use my own Linux box as the central place from which I run all my screen sessions. From those sessions I can ssh to remote machines to take care of all manner of business, and all I need to do to resume work remotely is to ssh to my box, and reattach the specific screen session needed (you may recall my open sessions to guinness and harp). This keeps my screens easy to manage, but also keeps ssh key management simple and centralized.
Thanks heaps – you’re a lifesaver