Unix server administrators everywhere are probably too familiar with connection timeouts when administering remote servers. There you are, dutifully editing that configuration file, when suddenly your text editor no longer responds to your cursor keys. A dozen seconds later or so, SSH reports the connection has been lost. If you didn’t save your file recently, you probably mutter a curse, for you probably have to redo your work all over again.
There is nothing worse than having to administer a server through a bad connection. When you are disconnected, having to reconnect, login, and navigate to where you last were, can knock you out of the flow of what you were doing, severely affecting your productivity.
screen to the rescue
Back in the time of the dinosaurs and dial-up, some GNU hackers, tired of the inconvenience just described, invented the screen application. screen creates a virtual console running on the server, which keeps the user logged in to the server, even when the network connection is lost. With screen, you will never lose your place while logged in remotely again, baring a reboot, shutdown, or power-loss to the server itself (alas, screen is not magic.)
screen can do much more than this simple description so far hints at. You can learn more from the online manual (type man screen at the command-line.) But for this hack, the following is all you need to remember:
Type in screen -DR when you first connect to your server, and your login session will be preserved through network disconnections. If you get disconnected, login again, and type screen -DR to return to your session, just as you left it.
The screen trick is all well and good. But we like to do things thoroughly at pjtrix, and try to find a full solution to the problem. So on to autossh we go.
autossh: aim for the kill
Keeping with the dinosaurs and dial-up theme, autossh is like an auto-redialer. It faithfully tries to reconnect you to your server again as soon as it detects the connection is gone. It does this by creating an SSH tunnel loop between your workstation and the remote server, and monitors it repeatedly for lost messages.
Using autossh is almost like using ssh: except for the connection monitoring specifics, autossh simply passes all command-line parameters to ssh, and after entering the command-line, all user interaction is done through the running ssh instance. To use autossh effectively with screen, type the following command to first connect to your remote server (use this command instead of ssh):
autossh -M monitoring-port -t username@server.domain.tld “screen -DR”
For example:
autossh -M 20000 -t webmaster@pjtrix.com “screen -DR”
With the above command, autossh creates an SSH tunnel loop with ports 20,000 and 20,001 for monitoring the connection; the -t parameter makes ssh create a pseudo-terminal when it connects to the server; ssh connects to the server pjtrix.com as user webmaster; and finally, ssh runs the command screen -DR remotely on the server immediately upon a successful connection and user authentication.
If for any reason the connection to the server drops, autossh detects this, and starts another ssh session, with the same commands. This effectively reconnects you to the server, logs you back in, and returns you to your screen session, right where you left off.
Used together, autossh and screen are real peace of mind savers for Unix system administrators. Couple this hack with an SSH authentication agent and SSH keys, and you don’t even have to remember your server password between reconnects.
Truly, there can never be greater Unix administration bliss than this.
Technorati Tags:
hacks, ssh, open.source
Very cool. I’ve used screen a little before, but autossh is a new one for me. One suggestion: when you feature things like these, it would be nice to have download links to the packages you mention. I know we can all use “The Google”, but one of a SysAdmin’s required attributes is laziness. At least, for me.
-k-
Ken,
Thanks for the suggestion! I will keep that in mind in the future.
I’m trying to keep hacks in 2007 as relevant, short and sweet as possible (as opposed to the previous SSH hack in 2006, which rambed quite a lot.) But including a few links at the end won’t hurt.