How to Reboot a Server Over SSH

There are two big things that matter for programmers: knowing what needs to be done, and doing it. So when a server that you SSH into tells you that it wants to be restarted, it’s nice to just do that quick SSH reboot. So long as you trust that nothing will break (a small but important thing), rebooting a server you only have access to over SSH isn’t too many steps.

If you like, here’s a video explaining how to reboot a remote server that you’ve connected to via SSH:

Step by Step Guide to Restarting a Remote Server using SSH Reboot

1. Log in to the server via SSH. Being able to log in isn’t enough on its own, though: rebooting takes the root account, or a user account that the server’s sudo policy permits to run the command.
2. Type sudo reboot. This will kick you out of the machine, because it’ll be powering down. You’ll need to wait for the reboot to finish, then you’ll be able to reconnect.
3. That’s basically it.

The video says a bit more. The big thing to know if that if you’re logged in as the “root” — most powerful — user on the system, the sudo is unnecessary. But if you’re instead just a normal user — which is generally recommended as a general security measure — you’ll need it. sudo is a simple command that basically means “for the stuff I type after this, use an elevate permissions level.” Or, in other words “as a ‘super-user'”.

Because non-root users don’t typically have the ability to reboot over SSH, you’ll need that to do so. But otherwise that’s all you need.

On modern Linux systems, you might also see sudo systemctl reboot used instead. This does the same thing. It’s just the systemd way of handling it. Either command works fine, so use whichever you’re comfortable with.

Another thing to note is that you’ll be disconnected if the command executes successfully. This makes sense. A system that’s powering off to then come back up will inherently drop all of it’s external connection, including the one to you via SSH.

One more tip: if you’re managing a production server or worried about active users, you can check who else is logged in with the who command before rebooting. It’s polite to make sure you’re not kicking someone else off mid-task. And if you’re working with a cloud platform like AWS or DigitalOcean, you have reboot options beyond SSH. AWS recommends rebooting EC2 instances from the EC2 console, CLI, or API instead of running the operating system’s reboot command, and when the reboot is started that way, Amazon EC2 performs a hard reboot if the instance doesn’t shut down cleanly within a few minutes. On DigitalOcean, the VNC-based Recovery Console stays reachable even when a Droplet has lost network access or its sshd process has failed, so it’s the way in when SSH itself won’t connect, as long as the Droplet has a root or sudo user password (on a key-only Droplet, set a root password from the DigitalOcean Control Panel first).

For more advice about using the Unix command line and more, check out this article.