Persistent PuTTY sessions for multiple windows

Question

I'm working in various Linux environments through PuTTY connections which break from time to time. I'm looking for a solution to make the PuTTY windows persist (e.g. if I was editing a file, then after reconnecting I should be in the same editor with the same file open at the same place), with the following requirements:

• it shouldn't require any manual setup at the beginning of the session or after reconnection (I don't want to type in screen or anything like that)
• I have several windows open to the same machine with the same user, which tend to disconnect at the same time
• the number/role of windows is not constant (it's not like I have an mc window, a mysql window and a "script runner" window; sometimes I use one window for search or for SVN commands, other times I need several at the same time)
• sometimes I need to change the properties of the windows for a task (large window for grepping/editing, small windows because I need to see two of them at the same time, red background because I am modifying the live database in MySQL etc), so I need to get the same console back in the same window after a reconnect

Is there a way to achieve this? I suppose I should use screen or something equivalent, but how does it know which window I am reconnecting from? Is there some way to pass a unique window identifier to the shell from PuTTY?

Solution 1

The quick and clean solution

Edit your ~/.bashrc to run screen -r. Then you will be reattached to a running screen session automatically when you log in.

The fulfilling solution

• Create a user for each screen session (Windows-window/PuTTY session) you intend to have open as a maximum.
• Connect to the server using each of the newly created users and run "screen -S username" to start a session named with their username.
• Append "screen -r $(whoami)" to each user's ~/.bashrc
• Save a putty session for each of the users on your desktop or in PuTTY to add them to your superbar's jumplist or wherever you want your shortcuts, and use them to start up each session. This will also enable you to

EDIT: I would preferrably focus on fixing the timeout issue. It's a security feature, I know, but it shouldn't disconnect you while you are sending input.

Solution 2

An old post I know, but just thought I'd mention the seconds between Keepalives setting on the Connection options tab - set this to a non-zero value to see if it helps - see http://the.earth.li/~sgtatham/putty/0.63/htmldoc/Chapter4.html#config-keepalive for more info.

Solution 3

Look into mosh which is designed to reconnect terminal sessions after transient network failures. There are a bunch of caveats with mosh (different security considerations, potential loss of scrollback), but it definitely solves the re-connect-after-disconnect much smoother than putty.

Comments

[ganesh]

Screen or Tmux would indeed work, but I think that this would be working around symptoms. The real problem is that your network connections die somehow, taking your puTTYs with them. The real goal should be fixing that, not finding a way to work around restarting your ssh sessions (This will also affect other programs which will suffer from the same connection drops).

[mnmnc]

You need a custom script running in the background, tracing your current actions (started commands) and logging them periodically updating the file - lets call it current.com. This file with contain all currently active jobs started by a specific user. After disconnection and re-connection, the profile.rc will start the script which will start all commands that it finds in "current.com" file. The script can use screen command so you could have a split screen if you prefer. The script tracing the active commands could potentially distinguish running jobs based on the tty ID.. tbc

[mnmnc]

...and place the jobs in the separate files current.com1 current.com2 and so on. Then after reconnecting the script started by profile.rc would reconnect the first inactive group of commands to your reconnected session. If you connect the parallel session it would restart the second group of inactive jobs and so on... I do not think there is an existing tool for your demands but the script should not be that complicated to write.

[mnmnc]

@Hennes the timing out of inactive sessions is not a bug - its a feature and very important from the security point of view I might add. This is not something you should work-around. You can adjust the timeout settings on the server side in sshd.conf but you should never set it up to keep the session indefinitely.

[ganesh]

I disagree. The time-out are not a replacement for security features. -- If I ssh into my server, take a coffee break (with locked desktop. On windows simple win-L), come back after the break and unlock my desktop then I do not expect my putty sessions die have died.

[mnmnc]

@Hennes There is a difference between the coffee break and weekend break. You can adjust the timeout to 30 minutes for example. But session that will hang for hours is a security risk whether you like it or not. It doesn't matter if you lock the PC or not. You are limiting the security from two-password access to single password access. Accidents happen, you might left the office in a hurry, the session will hang. Your colleague who knows your password (don't say he doesn't - not the point) will have access not only to your PC but to remote PC as well and his actions will go on your account.

[Tgr]

Not really a network issue, for example sessions drop when I take the laptop with me for a meeting and it has no connection while I am moving between access points. The connection dropping only happens in expected cases, and most of my applications just auto-reconnect; I want to set up the same for PuTTY.

[Tgr]

@mnmnc: automatically reissuing commands I used sounds scary, and anyway, doesn't solve the problem of getting the same session back in the same window. If I just want to get back one of the existing sessions randomly, I can probably achieve that by calling screen with the right parameters in .bashrc.

[Steen Schütt]

This could be solved by using side-by-side windows within screen instead of multiple SSH sessions.

[mnmnc]

Yeap - but only if you use single side by side session. If you use Text editor in one Putty session and on the other Putty session you use screen with split workspace - how would you reconnect to all of them?

[Steen Schütt]

That wasn't what I meant, I meant you could keep the text editor in a split workspace. Either way, this is more of a workaround than a solution. You could also use fixed screen session names. e.g. you create a user named steve, steve starts a screen session with "screen -S steve". You also create a user named greg, greg then starts his session with "screen -S greg". Edit each user's .bashrc to reattach to their respective session with "screen -r steve" and create a saved PuTTY session for each user.

[mnmnc]

Yes. That is a nice solution - I agree. However I think I would not decide to do this as I would need to have potentially as many Users as combinations of screens with which I work. This means if i would like to change some settings for my profile globally, i would need to propagate those settings to all .profilerc files - am I right?

[Steen Schütt]

Since you never close the screen session, but just reattach to it, all your settings will be saved. If you need to change something, you can just do it within the screen session. What kind of settings are you thinking of?

[Tgr]

The different users are not really necessary, I can have several different PuTTY configs for the same user, with different environment variables. But I am hoping for a nicer solution where PuTTY somehow passes an identifier to the shell (its a Windows process ID, for example), and I can use that as the name for a names screen session. That way I do not have to pollute my PuTTY host list, and do not have to think which user/config to use if I need a new window.

[Tgr]

As for multi-windows in screen, I am used to the Windows way of manipulating windows and don't want to learn a completely different approach just because of this. And in general, text-based window emulation is a big help when you are on a dumb terminal, but a poor replacement for real windows (e.g. I use dual monitors, I can't take advantage of that with screen multi-windows). I also have some window-related convenience settings (e.g. blink window name on toolbar when a long task is done) which I would have to solve in a different way.

[Steen Schütt]

I know the deal with multi-monitors, as I have them myself. I haven't ever felt the need for multiple sessions on the same server though. I'm perfectly fine with ^A+0, ^A+1 etc. Back on topic though, the idea is that you can create jumplist or desktop shortcuts to each screen session, which effectively solves his problem, but in a quick an dirty manner. But again, the SSH connection should stay alive while you are using it, and this is the issue I would try to fix first.

[Tgr]

Thanks. I heard about mosh, but as I understand it basically replaces SSH with its own protocol which is probably not mature enough for serious use.