Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
5  
I can't believe no one has mentioned mosh.mit.edu –  jwbensley Jun 27 '13 at 14:38
    
@javano: I have never heard of it. Add that as an answer! –  kbyrd Nov 23 '13 at 18:36
    
@kbyrd Have done ;) –  jwbensley Nov 24 '13 at 13:02

12 Answers 12

up vote 79 down vote accepted

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.

share|improve this answer
3  
Or use tmux - a 'cooler' screen, I've used both and much prefer tmux because you can split the term nicely. –  John Hunt Sep 19 '12 at 13:38

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.

share|improve this answer
10  
So far, you seem to be the only one actually answering the question instead of suggesting screen as a workaround. –  kbyrd Jun 4 '09 at 13:20
1  
Good call. We've found this method particullarly useful when traversing cisco ASA/PIX firewalls, which by default love to time out tcp connections. –  Mike Pountney Jun 4 '09 at 13:21
5  
Maybe this isn't the right place to ask, but is it possible for the poster to switch answers? We should the 'screen' answer (mine's not the best, I like Mike Pountney's, but I got the rep) in with this information. –  kbyrd Jun 4 '09 at 13:27
    
Will this work when connected over a Cisco VPN connection, and the VPN connection is lost and re-established? –  Brent Jun 4 '09 at 14:26

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:

  • Start a screen session (on your remote host):

    $ screen

  • Disconnect from your screen session: CTRL-A, d

  • Reconnect to your screen session after logging back in again:

    $ screen -d -r

  • Open another screen 'window': CTRL-A, c

  • Cycle through you open screen windows: CTRL-A, space

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.

share|improve this answer
1  
Yea, this is a much better answer than mine. –  kbyrd Jun 4 '09 at 13:20

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

screen -ls

to view your sessions and

screen -r ${session}

to reconnect to a disconnected one.

share|improve this answer

autossh watches your connection and if it goes down, it reconnects. It is more reliable than keepalives.

share|improve this answer
    
outside of a configurable keep-alive, it doesn't inherently allow you to reconnect to a session (what the OP was looking for). but autossh can be really helpful for apps that require ssh tunnels, port mapping, etc. –  ives Dec 17 at 0:26

I can't believe no one has mentioned MOSH;

Mosh is an SSH wrapper, it keeps your session alive after days of disconnection, changing IP, high latency and so on. It is explain on the home page better than I can explain it so I have copied the description below. My experiences and advice are that I use it on my Android mobile, it's a life saver when travelling and SSH'ing. The same is true on my laptop when tethered with mobile on the train for example. I recommend compiling from source to get the latest version, the repo version for me inside Ubuntu has a few annoyances in it which are fixed in the newest version.

Mosh (mobile shell)

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh is free software, available for GNU/Linux, FreeBSD, Solaris, Mac OS X, and Android.

Features from the website:

  • Change IP. Stay connected: Mosh automatically roams as you move between Internet connections. Use Wi-Fi on the train, Ethernet in a hotel, and LTE on a beach: you'll stay logged in. Most network programs lose their connections after roaming, including SSH and Web apps like Gmail. Mosh is different.

  • Makes for sweet dreams: With Mosh, you can put your laptop to sleep and wake it up later, keeping your connection intact. If your Internet connection drops, Mosh will warn you — but the connection resumes when network service comes back.

  • Get rid of network lag: SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. It does this adaptively and works even in full-screen programs like emacs and vim. On a bad connection, outstanding predictions are underlined so you won't be misled.

  • No privileged code. No daemon: You don't need to be the superuser to install or run Mosh. The client and server are executables run by an ordinary user and last only for the life of the connection.

  • Same login method: Mosh doesn't listen on network ports or authenticate users. The mosh client logs in to the server via SSH, and users present the same credentials (e.g., password, public key) as before. Then Mosh runs the mosh-server remotely and connects to it over UDP.

  • Runs inside your terminal, but better: Mosh is a command-line program, like ssh. You can use it inside xterm, gnome-terminal, urxvt, Terminal.app, iTerm, emacs, screen, or tmux. But mosh was designed from scratch and supports just one character set: UTF-8. It fixes Unicode bugs in other terminals and in SSH.

  • Control-C works great: Unlike SSH, mosh's UDP-based protocol handles packet loss gracefully, and sets the frame rate based on network conditions. Mosh doesn't fill up network buffers, so Control-C
    always works to halt a runaway process.

share|improve this answer

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).

share|improve this answer
    
Nice script in that link, thanks! –  palehorse Jun 4 '09 at 14:26

You can use screen. Screen sessions can be detached (when connection is lost) and resumed later on a different or the same terminal.

share|improve this answer

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.

share|improve this answer

The screen solution is the more practical and secure, i use it everyday and with an autoconnect script is a live saver!

share|improve this answer

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.

share|improve this answer
    
Thanks for the suggestion. We are working on tracking down the root problem of packet loss, it's simply taking a while to figure it out (very tricky, this one!). This really is a work-around for this trouble period. One never knows when something will cause a dropped connection. –  palehorse Jun 4 '09 at 13:40
    
It will generate a lot of noise, but you can try running ssh through strace and see what it doing/reports when the ssh connection drops. It might just report what you already know, but who knows... –  David Jun 4 '09 at 15:42

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.