OLEshiy
asked on
Restore SSH session after network breakdown (not using SCREEN)
This question bothers me for so long - is there any way to restore ssh (pts) session after client's disconnetion?
Here is an algorythm:
1. # ssh username@some.remotehost.c
2. open several interactive programms (mc, vim etc)
3. plug of network cable from client's computer :-)
4. open ssh connection from another computer and run:
# who
username pts/3 Apr 10 14:04 (192.168.1.2) <------ this session must be restored
root pts/6 Apr 2 11:04 (192.168.1.3)
root pts/7 Apr 5 15:39 (192.168.1.4)
.....
5. huh? what to do?
Here is an algorythm:
1. # ssh username@some.remotehost.c
2. open several interactive programms (mc, vim etc)
3. plug of network cable from client's computer :-)
4. open ssh connection from another computer and run:
# who
username pts/3 Apr 10 14:04 (192.168.1.2) <------ this session must be restored
root pts/6 Apr 2 11:04 (192.168.1.3)
root pts/7 Apr 5 15:39 (192.168.1.4)
.....
5. huh? what to do?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please enlighten me.
I believe to have heard before that someone say that this is possible. On the server side you would have to make the TTL of the session to last longer and that the client has a fix ip. In order for SSH to work, you would require a 3 factor authentication which is the IP address, Application ID and also the SSL cert.
One can spoof the ID and maybe the Application ID but not the same cert right? The user will still need to relogin username and password to continue its session. I've seen it working but not the actual steps on how its being done. The reason behind it was that dial-up users which has slow connectivity find it a hassle if the connection drops half way and their password gets locked.
I believe to have heard before that someone say that this is possible. On the server side you would have to make the TTL of the session to last longer and that the client has a fix ip. In order for SSH to work, you would require a 3 factor authentication which is the IP address, Application ID and also the SSL cert.
One can spoof the ID and maybe the Application ID but not the same cert right? The user will still need to relogin username and password to continue its session. I've seen it working but not the actual steps on how its being done. The reason behind it was that dial-up users which has slow connectivity find it a hassle if the connection drops half way and their password gets locked.
> dr_shivan
It seems you have missed some stuff from the original post
You say:
> On the server side you would have to make the TTL of the session to last longer *and that the client has a fix ip*
And what OLEshiy asked for:
> 4. open ssh connection from *another* computer and run:
It seems you have missed some stuff from the original post
You say:
> On the server side you would have to make the TTL of the session to last longer *and that the client has a fix ip*
And what OLEshiy asked for:
> 4. open ssh connection from *another* computer and run:
dr_shivan, really I tested such 'session restoration' what you are talking about, but from the same host (FreeBSD with some minor TCP tuning)
to restore/resume a session, you can use VNC or freenx (NX client).
VNC is packaged in most of Linux distribution.
freeNX and NX client you can download from
http://www.nomachine.com/download.php
Basically, those two tools allow you to resume/restore the remote terminal session, doesn't matter via telnet or SSH.
It allows you to resume/restore from other machine as well.
VNC is packaged in most of Linux distribution.
freeNX and NX client you can download from
http://www.nomachine.com/download.php
Basically, those two tools allow you to resume/restore the remote terminal session, doesn't matter via telnet or SSH.
It allows you to resume/restore from other machine as well.
ASKER
Ok, let me paraphrase my question: is there any way to connect to existing pseudo-terminal (analogue to screen -x)?
As you've said above, every ssh-connection opens (or creates?) pseudo terminal. When netwotk connection breaks down, that pts remains alive for some time (according to such sshd configuration as "timeout", "keepalive" etc). I have root privelegies on the server.
As you've said above, every ssh-connection opens (or creates?) pseudo terminal. When netwotk connection breaks down, that pts remains alive for some time (according to such sshd configuration as "timeout", "keepalive" etc). I have root privelegies on the server.
VNC or NX can fit your need just fine.
You can resume the VNC or NX session from any other machine if the network connection breaks down.
Those tools basically keep the session alive, unless you kill then or reboot, even thouth the network connection breaks down.
ssh or SSL for VNC or NX is used to encrypted the connection from client to server. After connection, it looks for the existing session first.
So you can easy to resume your session without deal with restoring ssh session.
I use NX/VNC at work and suspend it when I leave for home. Then resume the session at home when I need it.
You can resume the VNC or NX session from any other machine if the network connection breaks down.
Those tools basically keep the session alive, unless you kill then or reboot, even thouth the network connection breaks down.
ssh or SSL for VNC or NX is used to encrypted the connection from client to server. After connection, it looks for the existing session first.
So you can easy to resume your session without deal with restoring ssh session.
I use NX/VNC at work and suspend it when I leave for home. Then resume the session at home when I need it.
ASKER
Thanks for all advices, but I still haven't heard an answer to my last question: is there any way to connect to existing pseudo-terminal?
> is there any way to connect to existing pseudo-terminal?
No.
No.
sirbounty, hi.
The correct answer is here, was first suggested by PsiCop. There is _no_ possible way to connect to dead ssh session and it _is_ correct answer.
The correct answer is here, was first suggested by PsiCop. There is _no_ possible way to connect to dead ssh session and it _is_ correct answer.
Forced accept.
Computer101
EE Admin
Computer101
EE Admin
I'm completely agree with PsiCop, you cannot connect to already dead session.
However _theoretical_ small possibility exists, on modified system.
OpenSSH uses openpty() library call (libutil) to allocate a pseudo terminal device. This call is implemented differently on different systems, but on Linux it opens '/dev/ptmx' and /dev/pts/* devices (by name) to find first free pseudo terminal. So, it's theoretically possible to fake /dev/ptmx and create a node with the same name, but your own pseudo terminal multiplexor driver with some controlling process in a user space (much like screen). Then you may write program that can 'reconnect' such disconnected process and view the last screen. However you cannot fake 'ssh' to think that this tcp session is still alive (as correctly said by PsiCop) and any input will disconenect stale ssh session and kill your sshd.