0

My current use case passed to me on the job of screen usage is ssh to server, su to technical user account, then screen -RD. When ssh session is automatically lost due to timeout, I repeat the steps and have my "terminal status" on the server for that technical account looking same as if no connection reset happened.

I wanted to understand importance of -RD flags and on screen man page I've read (emphasis by me):

-D -R

Attach here and now. In detail this means: If a session is running, then reattach. If necessary detach and logout remotely first. If it was not running create it and notify the user. This is the author's favorite.

I've tried web search for logout remotely screen, relevant top result was only https://www.tecmint.com/keep-remote-ssh-sessions-running-after-disconnection/, where I've read about detaching:

Detaching a Screen

Just when you want to log out of the remote session, but you want to keep the session you created on that machine alive, then just what you need to do is detach the screen from the terminal so that it has no controlling terminal left. After doing this, you can safely logout.

On SE I've found How to remotely detach a screen from another terminal and https://askubuntu.com/questions/526972/remotely-log-out-of-graphical-gnome-session but these are other specific questions.

I've tried to read wiki on logging in, out etc but it is still not clear. What session can I logout remotely? I'm running screen on the server... Maybe these flags are irrelevant in my that specific use case? What is most common use case for -RD (remote logout)?

  • Haven't tested it, but I think it probably means that if the screen session is currently attached to another SSH session right now, it will detach and logout of that SSH session. – muru Oct 25 '19 at 8:02
2

When you run screen on the server, you actually have two terminal sessions at once: the first one you SSH'd in with, and a second, "local" one that is managed by the screen command. If the first session is terminated for any reason without exiting screen properly first, these two sessions will automatically separate from each other, and when you establish a new SSH session, screen allows you to reconnect to the existing second session.

If the timeout that is cutting off your connections is something like a firewall cutting off an existing connection for inactivity, the problem in that is the firewall may have no method to signal the cut-off to either end of the connection, until the end in question attempts to send something over the connection that has been cut off.

So if the firewall cuts off the SSH connection and you then enter even a single character on the SSH connection, the firewall will send back a TCP Reset to the SSH client and you see that the connection has been cut off. But the SSH server side is not necessarily aware of it: if the server has not attempted to send anything to you, it may still be sitting there, waiting for any input from you, on a TCP connection that is -as far as the server knows- still connected but idle.

In this particular case, you'll need the -D option in the screen -DR to rip off the screen session from the old SSH session even if screen thinks it is still connected.

As a side effect, it will cause the server to attempt to send output (the "disconnected" message from screen, and a new shell prompt) on the initial, cut-off SSH session, the firewall will send a TCP Reset back, and so the sshd on server side will finally get the information that the old SSH connection has been interrupted at the network level, and will clean it up.

But if the thing causing your SSH session to time out is something at the server causing your first SSH session to terminate, for example the server administrator setting the ClientAliveCountMax to 0 in sshd_config and ClientAliveInterval to some non-zero value as a hack to get a sort-of inactivity timeout from sshd, then your old SSH session will have fully disconnected and the screen session will already be waiting for you in an already-separated state. In that case, just screen -R would be sufficient to reconnect to it... but additionally specifying the -D option won't hurt in this case.


By the way, abusing the ClientAliveInterval and ClientAliveCountMax settings in sshd_config that way is a pretty unreliable way to set up an user inactivity timeout, as the client side can work around it without knowing that they're doing it. This is because ClientAliveInterval is about monitoring activity on the level of the SSH connection, not actual user activity.

If the user of the SSH client is experiencing network timeout issues, they might set ServerAliveInterval in their ~/.ssh/config (or an equivalent setting on a non-OpenSSH client). If the client's ServerAliveInterval is set shorter than the firewall's connection inactivity timeout, it would cause the SSH client to automatically send an encrypted SSH "are you still there?" packet on inactivity, and the sshd at the server would reply to it, resetting the inactivity timers on the firewall.

But setting a client-side ServerAliveInterval with a shorter timeout value would also cause the server to never reach the ClientAliveInterval timeout as long as the SSH connection is actually working, defeating the supposed "user inactivity timeout".

Unfortunately some security hardening standard seems to have incorporated this ClientAliveInterval-based user inactivity timeout hack, and so some security auditors may require it, even though it's not really fit for its supposed purpose.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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