Restart SSH on a machine where SSH is the only mode of access
772
I've made some changes to sshd_config file and therefore need to restart. I'm looking tips on safely restarting ssh when getting physical access to the server would be a huga PITA.
Restarting sshd while logged in via ssh will not disconnect your ssh connection.
If you're worried about your configuration, log in a few times via ssh, and restart. If you can no longer ssh in, with new connections, you now have access to fix the problems.
Mentioned below in a comment by @Milan Babuškov: sshd -t will test your configuration for syntax correctness, if you really want to be certain.
Another suggestion, by @Ronald Pottol was to set up a cron task to restart the server with a known working configuration. Perhaps overkill, but if you're updating a mission critical server, etc... sometimes you can never be too careful.
If you have access to the hardware you may consider putting a terminal on the serial port /dev/ttyS0 . Then you can have a back door into your server.
simply add
SO:2345:respawn:/sbin/mingetty ttySO
to your /etc/inittab and a terminal will spawn over your serial port. You can use a serial port concentrator or use a null modem from the server next to it.
I have found that nowadays sshd does not disconnect your sessions when restarting, especially when it is a Redhat based distro. You could always write a small script that will automatically restore your sshd config from backup and restart sshd after 5 min as a cron or at job. This will ensure that even if you get disconnected, you can get back into your server at least.
I wouldn't recommend restarting/reloading SSHD on a sshd connection. I've seen many occasions where sshd just wouldn't start back up because of a syntax error in sshd_config.
Even though everything is ok with the config file, it's risky.
Restarting sshd while logged in via ssh will not disconnect your ssh connection.
If you're worried about your configuration, log in a few times via ssh, and restart. If you can no longer ssh in, with new connections, you now have access to fix the problems.
Mentioned below in a comment by @Milan Babuškov:
sshd -t
will test your configuration for syntax correctness, if you really want to be certain.Another suggestion, by @Ronald Pottol was to set up a
cron
task to restart the server with a known working configuration. Perhaps overkill, but if you're updating a mission critical server, etc... sometimes you can never be too careful.If you have access to the hardware you may consider putting a terminal on the serial port /dev/ttyS0 . Then you can have a back door into your server.
simply add
to your /etc/inittab and a terminal will spawn over your serial port. You can use a serial port concentrator or use a null modem from the server next to it.
Don't worry, your current session won't be disconnected, even if there's a problem with the new configuration.
After applying the new configuration and restarting sshd, just try to login a couple of times and take a look at the logs to see if everything is ok.
Or, use a cron or at job to start it back up, if you are feeling unlucky?
Could you not Just run a kill -HUP in the PID of the SSH service? Its not clean but it works
I have found that nowadays
sshd
does not disconnect your sessions when restarting, especially when it is a Redhat based distro. You could always write a small script that will automatically restore yoursshd
config from backup and restartsshd
after 5 min as acron
orat
job. This will ensure that even if you get disconnected, you can get back into your server at least.I wouldn't recommend restarting/reloading SSHD on a sshd connection. I've seen many occasions where sshd just wouldn't start back up because of a syntax error in sshd_config.
Even though everything is ok with the config file, it's risky.