1

I am using Putty very often to SSH into Linux servers. In some cases, I won't leave the SSH session by typing exit, but by rebooting the remote machine.

Until one or two years ago, upon reboot, the OpenSSH server on the Linux machine obviously did notify Putty that the session has ended, which is what I want. Putty then used to close the session cleanly and immediately, and I could restart the session in no time (as soon as the rebooted server came back).

When I upgraded the Linux servers to Debian Wheezy or Jessie (I can't remember exactly), this useful behavior stopped. Now, when rebooting the remote servers, Putty doesn't get notified about the session end and tries to keep the session until it runs into timeout (after one minute or so).

Since I hadn't changed Putty's configuration for a long time, I suppose that the respective behavior of OpenSSH has changed. Although I have read the complete man page of OpenSSH, I could not find any option which (in my limited understanding) could be related to that problem, hence the question:

Is there a typical mistake in OpenSSH's configuration which could cause the "misbehavior"? Which option could be responsible?

EDIT:

This question might be a duplicate. But the solution / answer which is given in the duplicate does not work for me although I have the same setup as the OP. So something might be wrong with the solution given there, and I just thought it would be better to ask a new question instead of writing a comment to a question which has been asked over a year ago.

Binarus
  • 519
  • 3
  • 15
  • 3
    This is only an educated guess, but I think the most probable reason for this behavior is the new init system, `systemd`, which replaces `sysvinit` system. It could be that the init system disables network interfaces before killing the SSH daemon, therefore the connection eventually ends with a timeout. – Tero Kilkanen Oct 14 '16 at 17:36
  • @TeroKilkanen Or it only shuts down the `sshd` process listening on port 22, but leave the child processes handling connected clients alive. Shutting down `sshd` that way certainly makes sense in other cases, because then you can still use the active session to do whatever you want to do after shutting down `sshd`. For shutting down or rebooting, I always prefix the command with `exec`, which has avoided these kinds of problems for me. – kasperd Oct 16 '16 at 01:08
  • @TeroKilkanen Yes, it has to do with systemd, something like "user slice" vs. "system slice". I have made some tests, but to no avail. I think it's because I disable PAM in the OpenSSH server configuration, but PAM seems to be the only way to notify the user sessions when sshd is shut down. Since I am not ready to enable PAM for sshd, I'll just leave it as is and live with it. It seems that the newest version of the OpenSSH server addresses this problem. Simply waiting five years until Debian uses this version will save the problem, and that's the way I'll go. – Binarus Oct 18 '16 at 14:53

0 Answers0