SSH sessions hang on shutdown/rebootOpenSSH 6.7 end of sessionCentos 5 VPS: sshd freezesHow to automate SSH login with password?ssh returns “Bad owner or permissions on ~/.ssh/config”AT&T U-verse IRC, SSH, etc. sessions droppingTCP Sessions Hanging with Debian and iptablesSSH on Debian: Password prompt hangSSH file transfers hang after ~700KBFrequent interruptions of SSH connection to VPSGracefully logout all connected ssh users on rebootOpenSSH 6.7 end of session
Why is there no current between two capacitors connected in series?
1950s or earlier book with electrical currents living on Pluto
tikz: 5 squares on a row, roman numbered 1 -> 5
Parse a C++14 integer literal
How to become an Editorial board member?
Best practice for printing and evaluating formulas with the minimal coding
What does it mean to "take the Cross"
How could the B-29 bomber back up under its own power?
How can I prevent Bash expansion from passing files starting with "-" as argument?
How do you cope with rejection?
Was murdering a slave illegal in American slavery, and if so, what punishments were given for it?
What variables do I have to take into consideration when I homebrew armour?
On a piano, are the effects of holding notes and the sustain pedal the same for a single chord?
Department head said that group project may be rejected. How to mitigate?
Separate the element after every 2nd ',' and push into next row in bash
Is there any mention of ghosts who live outside the Hogwarts castle?
What are the domains of the multiplication and unit morphisms of a monoid object?
Germany rejected my entry to Schengen countries
Mikrokosmos, BB 105, Vol. 1: No. 17 Contrary Motion (1) - Can't understand the structure
Presenting 2 results for one variable using a left brace
If you attack a Tarrasque while swallowed, what AC do you need to beat to hit it?
Does science define life as "beginning at conception"?
Schwa-less Polysyllabic German Noun Stems of Germanic Origin
How should I mix small caps with digits or symbols?
SSH sessions hang on shutdown/reboot
OpenSSH 6.7 end of sessionCentos 5 VPS: sshd freezesHow to automate SSH login with password?ssh returns “Bad owner or permissions on ~/.ssh/config”AT&T U-verse IRC, SSH, etc. sessions droppingTCP Sessions Hanging with Debian and iptablesSSH on Debian: Password prompt hangSSH file transfers hang after ~700KBFrequent interruptions of SSH connection to VPSGracefully logout all connected ssh users on rebootOpenSSH 6.7 end of session
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I have a server that runs Debian and sshd on it, and in case I need to reboot the server my SSH session hangs at client side until TCP timeout. I assume this is because when sshd is being terminated it does not explicitly close open SSH sessions to the host. What should I do to make sshd first disconnect everyone, then terminate itself as normal? So far I don't see a parameter in man sshd_config that's related to shutsown behavior.
ssh debian systemd
edited Jul 17 '15 at 9:34
n.st
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
add a comment |
I have a server that runs Debian and sshd on it, and in case I need to reboot the server my SSH session hangs at client side until TCP timeout. I assume this is because when sshd is being terminated it does not explicitly close open SSH sessions to the host. What should I do to make sshd first disconnect everyone, then terminate itself as normal? So far I don't see a parameter in man sshd_config that's related to shutsown behavior.
ssh debian systemd
edited Jul 17 '15 at 9:34
n.st
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05
add a comment |
I have a server that runs Debian and sshd on it, and in case I need to reboot the server my SSH session hangs at client side until TCP timeout. I assume this is because when sshd is being terminated it does not explicitly close open SSH sessions to the host. What should I do to make sshd first disconnect everyone, then terminate itself as normal? So far I don't see a parameter in man sshd_config that's related to shutsown behavior.
ssh debian systemd
edited Jul 17 '15 at 9:34
n.st
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
I have a server that runs Debian and sshd on it, and in case I need to reboot the server my SSH session hangs at client side until TCP timeout. I assume this is because when sshd is being terminated it does not explicitly close open SSH sessions to the host. What should I do to make sshd first disconnect everyone, then terminate itself as normal? So far I don't see a parameter in man sshd_config that's related to shutsown behavior.
ssh debian systemd
ssh debian systemd
edited Jul 17 '15 at 9:34
n.st
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
edited Jul 17 '15 at 9:34
n.st
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
edited Jul 17 '15 at 9:34
n.st
604514
edited Jul 17 '15 at 9:34
n.st
604514
edited Jul 17 '15 at 9:34
n.st
604514
604514
asked Jul 17 '15 at 8:16
VesperVesper
4811422
asked Jul 17 '15 at 8:16
VesperVesper
4811422
asked Jul 17 '15 at 8:16
VesperVesper
4811422
4811422
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05
add a comment |
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05
add a comment |
6 Answers
6
active
oldest
votes
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way of closing the client connection gracefully.
Your first thought might be to just kill all SSH processes as the first step during shutdown, and there are quite a few systemd service files out there that do just that.
But there is of course a neater solution (how it's "supposed" to be done): systemd-logind.systemd-logind keeps track of active user sessions (local and SSH ones) and assigns all processes spawned within them to so-called "slices". That way, when the system is shut down, systemd can just SIGTERM everything inside the user slices (which includes the forked SSH process that's handing a particular session) and then continue shutting down services and the network.
systemd-logind requires a PAM module to get notified of new user sessions and you'll need dbus to use loginctl to check its status, so install both of those:
apt-get install libpam-systemd dbus
Be sure your /etc/ssh/sshd_config is actually going to use the module with UsePAM yes.
edited Nov 7 '17 at 2:45
Tullo_x86
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead ofreboot, do ashutdown -rwhich defaults to a 1 minute delay, leaving you time to close the SSH session.
– mivk
Oct 30 '16 at 19:20
add a comment |
This is something you need to set on the client side, not the server side. Edit your ~/.ssh/config to contain
ServerAliveInterval 15
ServerAliveCountMax 5
This means that after 15 seconds of inactivity, your client will send a message to the server. If it doesn't get any response, it will try again up to 5 times, and when it still doesn't get an answer, it'll close the session.
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
add a comment |
This behaviour is reported on this Debian Bug, you only need to setup correctly the shutdown scripts shiped with the package because, automatically, they aren't copied by default:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
answered Mar 18 at 11:37
RfraileRfraile
344210
add a comment |
You can specify the options that Jenny D talked about in her answer just for one ssh command, such as
ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff
if you do that often, you can script it.
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
add a comment |
Works for me with lshd. So the solution would be
apt install lsh-server
apt remove openssh-server
answered Aug 3 '15 at 14:57
godgod
12117
add a comment |
sadly serverfault didn't let me answer in thread cause by too few points since years.
But I don't need to spam in other blogs to get the unlocking ^^... so as dedicated answer:
As Rfraile mentioned
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
works. To be using it without reboot the instance/server you should do additional tasks:
systemctl daemon-reload
systemctl start ssh-session-cleanup.service
so the service is registered and started and systemd needs to stop it for reboot/shutdown purposes.
answered May 7 at 16:55
Reiner030Reiner030
485
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f706475%2fssh-sessions-hang-on-shutdown-reboot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way of closing the client connection gracefully.
Your first thought might be to just kill all SSH processes as the first step during shutdown, and there are quite a few systemd service files out there that do just that.
But there is of course a neater solution (how it's "supposed" to be done): systemd-logind.systemd-logind keeps track of active user sessions (local and SSH ones) and assigns all processes spawned within them to so-called "slices". That way, when the system is shut down, systemd can just SIGTERM everything inside the user slices (which includes the forked SSH process that's handing a particular session) and then continue shutting down services and the network.
systemd-logind requires a PAM module to get notified of new user sessions and you'll need dbus to use loginctl to check its status, so install both of those:
apt-get install libpam-systemd dbus
Be sure your /etc/ssh/sshd_config is actually going to use the module with UsePAM yes.
edited Nov 7 '17 at 2:45
Tullo_x86
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead ofreboot, do ashutdown -rwhich defaults to a 1 minute delay, leaving you time to close the SSH session.
– mivk
Oct 30 '16 at 19:20
add a comment |
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way of closing the client connection gracefully.
Your first thought might be to just kill all SSH processes as the first step during shutdown, and there are quite a few systemd service files out there that do just that.
But there is of course a neater solution (how it's "supposed" to be done): systemd-logind.systemd-logind keeps track of active user sessions (local and SSH ones) and assigns all processes spawned within them to so-called "slices". That way, when the system is shut down, systemd can just SIGTERM everything inside the user slices (which includes the forked SSH process that's handing a particular session) and then continue shutting down services and the network.
systemd-logind requires a PAM module to get notified of new user sessions and you'll need dbus to use loginctl to check its status, so install both of those:
apt-get install libpam-systemd dbus
Be sure your /etc/ssh/sshd_config is actually going to use the module with UsePAM yes.
edited Nov 7 '17 at 2:45
Tullo_x86
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead ofreboot, do ashutdown -rwhich defaults to a 1 minute delay, leaving you time to close the SSH session.
– mivk
Oct 30 '16 at 19:20
add a comment |
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way of closing the client connection gracefully.
Your first thought might be to just kill all SSH processes as the first step during shutdown, and there are quite a few systemd service files out there that do just that.
But there is of course a neater solution (how it's "supposed" to be done): systemd-logind.systemd-logind keeps track of active user sessions (local and SSH ones) and assigns all processes spawned within them to so-called "slices". That way, when the system is shut down, systemd can just SIGTERM everything inside the user slices (which includes the forked SSH process that's handing a particular session) and then continue shutting down services and the network.
systemd-logind requires a PAM module to get notified of new user sessions and you'll need dbus to use loginctl to check its status, so install both of those:
apt-get install libpam-systemd dbus
Be sure your /etc/ssh/sshd_config is actually going to use the module with UsePAM yes.
edited Nov 7 '17 at 2:45
Tullo_x86
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way of closing the client connection gracefully.
Your first thought might be to just kill all SSH processes as the first step during shutdown, and there are quite a few systemd service files out there that do just that.
But there is of course a neater solution (how it's "supposed" to be done): systemd-logind.systemd-logind keeps track of active user sessions (local and SSH ones) and assigns all processes spawned within them to so-called "slices". That way, when the system is shut down, systemd can just SIGTERM everything inside the user slices (which includes the forked SSH process that's handing a particular session) and then continue shutting down services and the network.
systemd-logind requires a PAM module to get notified of new user sessions and you'll need dbus to use loginctl to check its status, so install both of those:
apt-get install libpam-systemd dbus
Be sure your /etc/ssh/sshd_config is actually going to use the module with UsePAM yes.
edited Nov 7 '17 at 2:45
Tullo_x86
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
edited Nov 7 '17 at 2:45
Tullo_x86
1034
edited Nov 7 '17 at 2:45
Tullo_x86
1034
edited Nov 7 '17 at 2:45
Tullo_x86
1034
1034
answered Jul 17 '15 at 9:20
n.stn.st
604514
answered Jul 17 '15 at 9:20
n.stn.st
604514
answered Jul 17 '15 at 9:20
n.stn.st
604514
604514
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead ofreboot, do ashutdown -rwhich defaults to a 1 minute delay, leaving you time to close the SSH session.
– mivk
Oct 30 '16 at 19:20
add a comment |
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead ofreboot, do ashutdown -rwhich defaults to a 1 minute delay, leaving you time to close the SSH session.
– mivk
Oct 30 '16 at 19:20
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
Okay, goal achieved, and thanks for the explanation. (Although I'd like some way of dependency control for shutdown, so that everything is first SIGTERM'd while being able to finish their work, this can do as a layered solution.)
– Vesper
Aug 3 '15 at 15:09
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
For some reason I wasn't notified about the answer while visiting only StackOverflow. Weird.
– Vesper
Aug 3 '15 at 15:10
1
1
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
So, for short, just to shave few seconds at shutdown, we have to install a whole load of crap just to have our connections terminated properly ? Seriously ? This is getting awry. We're doomed.
– leucos
Jun 29 '16 at 9:31
3
3
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead of
reboot, do a shutdown -r which defaults to a 1 minute delay, leaving you time to close the SSH session.– mivk
Oct 30 '16 at 19:20
Note that tjhe first reboot after installing libpam-systemd and dbus would still leave your SSH session hanging. To avoid that, instead of
reboot, do a shutdown -r which defaults to a 1 minute delay, leaving you time to close the SSH session.– mivk
Oct 30 '16 at 19:20
add a comment |
This is something you need to set on the client side, not the server side. Edit your ~/.ssh/config to contain
ServerAliveInterval 15
ServerAliveCountMax 5
This means that after 15 seconds of inactivity, your client will send a message to the server. If it doesn't get any response, it will try again up to 5 times, and when it still doesn't get an answer, it'll close the session.
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
add a comment |
This is something you need to set on the client side, not the server side. Edit your ~/.ssh/config to contain
ServerAliveInterval 15
ServerAliveCountMax 5
This means that after 15 seconds of inactivity, your client will send a message to the server. If it doesn't get any response, it will try again up to 5 times, and when it still doesn't get an answer, it'll close the session.
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
add a comment |
This is something you need to set on the client side, not the server side. Edit your ~/.ssh/config to contain
ServerAliveInterval 15
ServerAliveCountMax 5
This means that after 15 seconds of inactivity, your client will send a message to the server. If it doesn't get any response, it will try again up to 5 times, and when it still doesn't get an answer, it'll close the session.
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
This is something you need to set on the client side, not the server side. Edit your ~/.ssh/config to contain
ServerAliveInterval 15
ServerAliveCountMax 5
This means that after 15 seconds of inactivity, your client will send a message to the server. If it doesn't get any response, it will try again up to 5 times, and when it still doesn't get an answer, it'll close the session.
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
answered Jul 17 '15 at 8:36
Jenny DJenny D
24.4k116296
24.4k116296
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
add a comment |
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
2
2
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
This will result in 75s delay before ssh client reports server dead. Right?
– Vesper
Jul 17 '15 at 8:39
1
1
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
Yes, and you can adjust the parameters to get shorter timeout.
– Tero Kilkanen
Jul 17 '15 at 9:12
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
This solved the problem for me. Such an irritating problem.
– Justin Andrusk
Jun 28 '16 at 1:09
add a comment |
This behaviour is reported on this Debian Bug, you only need to setup correctly the shutdown scripts shiped with the package because, automatically, they aren't copied by default:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
answered Mar 18 at 11:37
RfraileRfraile
344210
add a comment |
This behaviour is reported on this Debian Bug, you only need to setup correctly the shutdown scripts shiped with the package because, automatically, they aren't copied by default:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
answered Mar 18 at 11:37
RfraileRfraile
344210
add a comment |
This behaviour is reported on this Debian Bug, you only need to setup correctly the shutdown scripts shiped with the package because, automatically, they aren't copied by default:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
answered Mar 18 at 11:37
RfraileRfraile
344210
This behaviour is reported on this Debian Bug, you only need to setup correctly the shutdown scripts shiped with the package because, automatically, they aren't copied by default:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
answered Mar 18 at 11:37
RfraileRfraile
344210
answered Mar 18 at 11:37
RfraileRfraile
344210
answered Mar 18 at 11:37
RfraileRfraile
344210
answered Mar 18 at 11:37
RfraileRfraile
344210
344210
add a comment |
add a comment |
You can specify the options that Jenny D talked about in her answer just for one ssh command, such as
ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff
if you do that often, you can script it.
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
add a comment |
You can specify the options that Jenny D talked about in her answer just for one ssh command, such as
ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff
if you do that often, you can script it.
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
add a comment |
You can specify the options that Jenny D talked about in her answer just for one ssh command, such as
ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff
if you do that often, you can script it.
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
You can specify the options that Jenny D talked about in her answer just for one ssh command, such as
ssh -t -o ServerAliveInterval=1 -o ServerAliveCountMax=1 user@host sudo poweroff
if you do that often, you can script it.
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
answered Dec 4 '16 at 2:12
Diego MedagliaDiego Medaglia
286
286
add a comment |
add a comment |
Works for me with lshd. So the solution would be
apt install lsh-server
apt remove openssh-server
answered Aug 3 '15 at 14:57
godgod
12117
add a comment |
Works for me with lshd. So the solution would be
apt install lsh-server
apt remove openssh-server
answered Aug 3 '15 at 14:57
godgod
12117
add a comment |
Works for me with lshd. So the solution would be
apt install lsh-server
apt remove openssh-server
answered Aug 3 '15 at 14:57
godgod
12117
Works for me with lshd. So the solution would be
apt install lsh-server
apt remove openssh-server
answered Aug 3 '15 at 14:57
godgod
12117
answered Aug 3 '15 at 14:57
godgod
12117
answered Aug 3 '15 at 14:57
godgod
12117
answered Aug 3 '15 at 14:57
godgod
12117
12117
add a comment |
add a comment |
sadly serverfault didn't let me answer in thread cause by too few points since years.
But I don't need to spam in other blogs to get the unlocking ^^... so as dedicated answer:
As Rfraile mentioned
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
works. To be using it without reboot the instance/server you should do additional tasks:
systemctl daemon-reload
systemctl start ssh-session-cleanup.service
so the service is registered and started and systemd needs to stop it for reboot/shutdown purposes.
answered May 7 at 16:55
Reiner030Reiner030
485
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
add a comment |
sadly serverfault didn't let me answer in thread cause by too few points since years.
But I don't need to spam in other blogs to get the unlocking ^^... so as dedicated answer:
As Rfraile mentioned
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
works. To be using it without reboot the instance/server you should do additional tasks:
systemctl daemon-reload
systemctl start ssh-session-cleanup.service
so the service is registered and started and systemd needs to stop it for reboot/shutdown purposes.
answered May 7 at 16:55
Reiner030Reiner030
485
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
add a comment |
sadly serverfault didn't let me answer in thread cause by too few points since years.
But I don't need to spam in other blogs to get the unlocking ^^... so as dedicated answer:
As Rfraile mentioned
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
works. To be using it without reboot the instance/server you should do additional tasks:
systemctl daemon-reload
systemctl start ssh-session-cleanup.service
so the service is registered and started and systemd needs to stop it for reboot/shutdown purposes.
answered May 7 at 16:55
Reiner030Reiner030
485
sadly serverfault didn't let me answer in thread cause by too few points since years.
But I don't need to spam in other blogs to get the unlocking ^^... so as dedicated answer:
As Rfraile mentioned
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
works. To be using it without reboot the instance/server you should do additional tasks:
systemctl daemon-reload
systemctl start ssh-session-cleanup.service
so the service is registered and started and systemd needs to stop it for reboot/shutdown purposes.
answered May 7 at 16:55
Reiner030Reiner030
485
answered May 7 at 16:55
Reiner030Reiner030
485
answered May 7 at 16:55
Reiner030Reiner030
485
answered May 7 at 16:55
Reiner030Reiner030
485
485
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
add a comment |
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
So are you just repeating another answer?
– RalfFriedl
May 7 at 18:45
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
No? I used the 2 lines only as reference for the upper reply because I can't reply yet as written. I added the necessary steps to use it without reboot. This may be given also in another question thread but that I haven't checked out.
– Reiner030
May 8 at 19:24
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f706475%2fssh-sessions-hang-on-shutdown-reboot%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
When all else fails, you can kill an SSH client at any time by pressing [Enter] [~] [.]. Explanation on how to actually solve your problem coming up as well.
– n.st
Jul 17 '15 at 9:05