Is there a way to connect to an ssh session that was disconnected? We are having problems with our network connection to a remote site that we are working on separately; however, in the mean time we experience a large number of disconnects due to lost packets while connected to servers at the remote location. Many times the session stays active for a while, and sometimes it happens to be in the middle of some action (file editing, running some process, etc...) that I need to get back to rather than restart if possible.
|
This isn't an answer, but a workaround. Use screen. When you first log in, run screen. You get another shell, run commands in that. If you're disconnected, the screen process keeps the terminal alive so that your shell and the processes it is running don't fall over. When you reconnect, run 'screen -r' to resume. There's a bunch more to configuring and using screen, but the above should workaround your problem. |
||||
|
|
Try to set ClientAliveInterval (e.g. 60) and TCPKeepAlive (yes or no) to appropriate values on the serverside sshd.conf . This should keep your session alive even if the connection gets lost for minutes. |
|||||||||||||||
|
|
As mentioned above, GNU Screen is the way to go. It will allow you to have a 'screen session' on the remote box that you can run multiple commands in, via multiple 'screen windows'. This will simply detach if your parent SSH connection dies, keeping all the subprocesses running within it alive and well. 'man screen' is your friend as usual, and the OS package should be called 'screen' if it is not installed by default. Basics are:
There is lots of cool stuff you can do with Screen. I've been using it for over 10 years, and still am finding out new features. It's my favourite Unix utility. |
|||||
|
|
I'd install and start screen to fix your problem. Screen will let you reconnect to a previous screen session. Apart from that, screen also let's you do cool things like split your screen, view the console etc. You can find more info here and here. For starters, if you get disconnected, you can use
to view your sessions and
to reconnect to a disconnected one. |
|||
|
|
|
autossh watches your connection and if it goes down, it reconnects. It is more reliable than keepalives. |
|||
|
|
|
You can use screen. Screen sessions can be detached (when connection is lost) and resumed later on a different or the same terminal. |
|||
|
|
|
As others have pointed out, screen is generally the best solution for this and it adds a host of other useful features too. You can setup your profile on the remote machine to automatically start and/or reconnect to screen on login, which saves you forgetting to start screen the one time you need it because you suffer a connection drop. See http://tlug.dnho.net/?q=node/239 (or search Google for many other examples dones slightly different ways). |
|||
|
|
|
Use screen Example for a debian/ubuntu server, including installing screen if it's missing (comments start with #):
later that day:
now you see your tail still running for a quick reference type
Full manual: http://www.gnu.org/software/screen/manual/html_node/Overview.html#Overview |
|||
|
|
|
The screen solution is the more practical and secure, i use it everyday and with an autoconnect script is a live saver! |
|||
|
|
|
Autossh is a very useful way of doing this. It starts an ssh process and then monitors it - if the ssh connection drops, it will restart it again and reconnect. |
|||
|
|
|
a more modern alternative to screen, alas not available to some types of "virtualisation" (e.g. in cygwin you can have "screen", but not "tmux" due to the way it's designed), but wherever you have the option to install tmux, I'd strongly recommend to go for that one insted of screen. |
|||
|
|
|
While screen will keep your shell session open on the remote server if your ssh session drops, it won't do anything about the problem of ssh connections being dropped. As zero_r suggests, try tuning your ssh connection with keep alives and long timeouts. I suggest you track down the cause of the lost packets causing the problems and fix that instead of working around it. |
|||||
|