I changed the configuration in:


but the changes were only applied after rebooting the server. How to apply changes without a reboot?

  • You may use sudo service ssh restart to restart the service to take effect. But remember if you're connected through SSH, your session will be terminated.
    – AzkerM
    May 8 '14 at 17:09

Simply restart the sshd service:

sudo service sshd restart


sudo /etc/init.d/sshd restart

Just in case you are restarting remotely, the configuration should be checked first to make sure it will not fail to start:

sudo sshd -t
  • 10
    What if I'm on an ssh connection?
    – Anwar
    Dec 8 '15 at 14:08
  • 12
    nothing ... bouncing sshd is smart enough to permit existing ssh connections to merrily continue unabated Sep 4 '16 at 16:56
  • 6
    I do not recommend running anything in /etc/init.d directly. Use the "service" command.Most services won't care, but there are a few that do because they're impacted by environment variables. "service" ensures the environment is cleaned out. For example, running "sudo" leaves the HOME environment variable to your non-root home directory. Nov 16 '16 at 21:41
  • 1
    This doesn't work on Ubuntu 16.04 for me.
    – tarabyte
    Aug 3 '20 at 20:17
  • @maximyefremov DONT; you can reload instead as the question wanted, which is given in the answer from abu_bua
    – dlamblin
    Oct 31 '20 at 15:04

There's an even less intrusive way to do this, without restarting the SSH service.

From man sshd:

sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g. /usr/sbin/sshd.

So you can use a command like the following to send SIGHUP to the SSH server process:

sudo kill -SIGHUP $(pgrep -f "sshd -D")

The pgrep -f "sshd -D" part will return only the PID of the sshd daemon process that listens for new connections, since there are likely to be other PIDs for each active session that don't need the signal.

  • 3
    This is the safest (stribika.github.io/2015/01/04/secure-secure-shell.html) way to reload the config: "Be extremely careful when configuring SSH on a remote host. Always keep an active session, never restart sshd. Instead you can send the SIGHUP signal to reload the configuration without killing your session. You can be even more careful by starting a new sshd instance on a different port and testing that."
    – lucasart
    May 15 '19 at 7:59
  • Is there any meaningful difference to sudo pkill -HUP sshd?
    – AdamKalisz
    Jun 24 '19 at 17:14
  • @Adam You only want to HUP the listening process, not the active clients which are also sshd processes. sudo pkill -HUP -f "sshd -D" is a tempting alternative, but then pkill signals its own sudo parent since its full command line matches its own search pattern. You can come up with a pattern that doesn't match itself like ... -f "sshd -[D], but that obfuscates things a bit. I think the pgrep method is easier for learners to wrap their heads around.
    – Steven K
    Jun 25 '19 at 23:19

For Systemd Systems (Ubuntu default)

sudo systemctl reload sshd.service


 sudo systemctl reload sshd


 sudo /bin/systemctl reload sshd.service

For Sysvinit / Systemd (Linux from Scratch default and Unix systems)

sudo service sshd reload


sudo /etc/init.d/sshd reload

Ubuntu uses systemd: Here the service command passes the units: start, stop, status, and reload through to their systemctl/initctl equivalents.

sudo service ssh restart

will not do it. You need to restart sshd, not ssh:

sudo service sshd restart
  • 4
    Depends on the system configuration. In Lubuntu 14.04 sudo service ssh restart works great, whereas sudo service sshd restart reports "sshd: unrecognized service". Not sure why this varies though...
    – schulwitz
    Jan 15 '16 at 22:22

As root check

service --status-all | grep ssh

I had no sshd service, but had ssh service on Ubuntu server. Then

service ssh restart

Reload may be a better alternative to restart

sudo service sshd reload

under the hood it sends HUP signal to sshd daemon process almost the same way Steven K already answered. The difference is that this variant uses killproc function instead of kill command directly in order to send the signal in even more precise way (to reduce possible errors of sending signals to wrong processes). The configuration is reread without restarting/stopping the service.

Of course it worth to find out how exactly SSH deamon is called actually as others discussed.

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.