Sleep your Linux box and still SSH in: wake it, work, and let it sleep after

Why a sleeping box drops your SSH session

Suspend stops everything. The kernel freezes every process, the SSH daemon with the rest, and the network card stays powered only to listen for a wake-up packet. A client with a shell open sees the connection hang and time out; a client that connects afterwards finds nothing answering. Two failures, one cause: a machine that is asleep is running nothing.

The first failure is the one the forums are full of — the box suspended under you. The session manager judges idleness by the local seat, and an SSH shell is a remote login, so the idle timer runs on beneath it as if nobody were there: a build in that shell, an rsync halfway through, an sftp mount in use, none of it counted. The usual fix is systemd-inhibit around the daemon, or a script that holds an inhibitor while a connection exists. Both hold on existence, and existence is the wrong test: an sshfs mount exists for a week, a shell you forgot exists until you notice, and the machine stays up for both. The second failure is the one nobody scripts around: you connect and the box is already asleep, because it did what you told it to.

What changed: the free agent on the box sees an SSH shell and a file transfer over SSH as sessions, judges each by activity rather than existence, holds the machine only while the session is active, and lets it sleep ten minutes after the last thing happened. An idle shell holds nothing. The readings behind the rule were taken on an Ubuntu box of our own; the Mac and Windows halves are proven against a real SSH daemon on our build runners, not yet watched on a desk.

Make the box wakeable

Do this at the machine, once. Waking needs nothing installed on the box — the network card does it below the operating system — but the card has to be told to listen, and the machine has to be asleep rather than off.

• The adapter. Wake-on-LAN is a flag on the Ethernet port, and on most distributions it resets at every boot. With the free agent on the box, the row shows wakes may fail while the flag is off, and Prepare for wake in the row's Wake readiness section sets it — the answer reads Network adapter set to wake the machine. — and re-applies it at every start and every wake, so it holds through reboots; the section then reads Ready to wake ✓. By hand it is ethtool -s eth0 wol g at every boot; the compatibility check has the commands.
• The BIOS. Wake on LAN on under the board's power page — Wake on LAN, Power On By PCI-E or Resume by LAN — and ErP Ready, EuP 2013 and any deep-sleep mode off, because those cut the standby rail the card listens on. No software reaches this one.
• Sleep, not power off. systemctl suspend, the desktop's idle timer, or Sleep on the dashboard: suspend-to-RAM keeps the card powered and everything in memory, and the box comes back in a second or two with your tmux session where you left it. From full power-off a box listens only if the BIOS keeps the card fed; the plug row below is the route from off.
• The cable. Ethernet wakes reliably. Wi-Fi wakes rarely, only from sleep, and only when the adapter, its driver and the router's key rotation all cooperate; a laptop on Wi-Fi cannot be woken by packet at all.

Choose what sends the wake

The packet has to leave from inside the box's own network, so the choice is which always-on thing there does the sending. Four things can, and none of them is the box itself; how to wake a PC remotely walks each one. For the nightly copy below, the NAS that receives it is the natural sender.

• The Echo. Enable the skill, link your Rooster Wake account, and give it the box's name and address; your own Echo puts the packet on your own network, which is why it is free on every plan.
• The free agent on a box that stays on. Install it on the NAS, a Raspberry Pi or a Home Assistant box — or as a container on the NAS — and that box sends for every other machine on the network.
• A certified smart plug. For the server that is genuinely off, or frozen: it cuts and restores the mains, and a board set to start when power returns boots from cold, on the paid plans.
• A dongle you build. A Raspberry Pi Pico W in a printed case, for the network where nothing stays on: half a watt, and everything the agent carries.

Wake it, see it come up, connect

With a sender in place the box is a row on your dashboard with a green Wake button. Press it from any browser or the phone app and the packet goes out on the box's network a second or two later. Wake-on-LAN has no acknowledgement, so two things tell you it landed: with the free agent on the box the row turns green — up now — agent connected — the moment it is up, on every plan; and on Plus and Pro, wake confirmation watches the box's own network for it answering and tells you it came up, or that it did not and why.

Then connect over SSH, from a terminal or the SSH app on your phone. The agent reports the daemon's posture, so in the machine's settings on the dashboard the Connect section reads Connect as with the user name the agent found and SSH: listening on 22 beside it — or the port the box's sshd_config moved it to — with the link built from those facts, ssh://[email protected], and Use this. Press it, press Save, and the row carries a Remote Desktop button that opens the link in whatever handles ssh:// on the device in your hand — one label for every scheme. Pressed while the box is asleep it sends the wake, waits for the agent to say the machine is up, and opens the link as one press; on Plus and Pro it holds the box for ten minutes while you sign in. The suggested address is the box's own network's — edit it to the mesh address before Save if that is how you reach it — and a row that already has a link is offered Replace with this.

While you are connected: the row says in use — SSH

The row reads in use — SSH while you are working in a shell over SSH, and in use — rsync over SSH — or sftp, scp or git, whichever program is moving the bytes; an sshfs mount is sftp underneath — while a copy is running; a transfer program it has no name for reads in use — file transfer over SSH. The chip means the agent is holding the box; tap it and the note reads Somebody is working on this machine over SSH; it stays awake while they are active and sleeps ten minutes after they stop.

The rule is activity, not existence, and it is what makes an overnight shell and an sshfs mount safe. A session counts as active when it has shown activity inside the last ten minutes: a keystroke on its terminal, CPU time in its process tree, or bytes moving through a transfer. A build running in a shell you are not typing into counts — the work is work whether or not you are watching it. A shell sitting at its prompt does not: ten minutes after the last keystroke the row swaps the chip for SSH session idle, whose note says what will happen — Somebody is connected over SSH but has been idle for more than ten minutes, so the machine may go to sleep under them. Nothing is killed, and the box is free to sleep as its own settings and the meter's end decide. Type something and the hold is back at once; mosh, tmux and screen are your own tools for picking a session up after the next wake. Sleeping it yourself is Sleep on the row — ten sleeps a calendar month on the free plan, unmetered on Plus and Pro — and Keep awake…, on Plus and Pro, holds the box for a window you choose whatever the session is doing.

The nightly copy: wake, transfer, sleep, with no script on either end

The loop most homelab scripts exist for: a backup box asleep all day, up for the copy, asleep again after. On the paid plans a schedule wakes the box at the hour you choose, with retries and a record, and every resume opens with ten minutes of grace, so the copy has ten minutes to start before the meter's end can act. Start the rsync from the other end — the cron line on the NAS you already have — and the row reads in use — rsync over SSH while the bytes move: the box is held for as long as they do, four minutes or four hours, and a pause while rsync checksums a large file sits inside the ten-minute window.

When the last byte lands the agent holds the box for ten more minutes, and then the meter's end does what it does at the end of any hold. A box on a cable goes back to sleep by itself unless somebody is using it — on Windows, macOS and Linux. A box on a certified smart plug, on the paid plans, shuts down cleanly instead, because it comes back by cold boot rather than resume, and the switch stays on for the next Wake to cycle it. A Wi-Fi-only box with no plug is left to its own power settings, because nothing could wake it again. Nothing on the box scheduled the sleep, and nothing on the NAS sent one.

An sshfs mount, or an sftp session left open, gets the same rule and the opposite result: while it moves data it holds the box, and while it sits there it holds nothing, so a mount left up overnight does not keep the server out of sleep. Wake-on-LAN for a homelab has the arithmetic for the always-on side.

When the wake does nothing

Nearly every "it does not wake" is one of these seven, each with a check at the desk. The first six are the plain how-to's causes — the Windows ones for the PC on the same desk, the network ones for any box — and the seventh is SSH's own.

1. The adapter setting is off. Check Device Manager, the Ethernet adapter: Allow this device to wake the computer ticked under Power Management, Wake on Magic Packet Enabled under Advanced. A driver update can silently reset both; with the free agent on the machine, the dashboard's Wake readiness section catches it and offers the fix.
2. Fast startup is on, and you shut down. The machine is hibernated, not off, and the card is parked un-armed. Check Choose what the power buttons do: Turn on fast startup unticked. Or sleep the machine instead — sleep is the state the packet is best at.
3. The machine was off, not asleep. From full power-off a PC listens only if the BIOS keeps the card fed and the driver's after-shutdown wake is on; a Mac never listens. Check: sleep it, send the wake, and if that works the missing setting is the BIOS one.
4. It is on Wi-Fi. Check whether the cable is in. Waking over Wi-Fi works from sleep only when it works at all, and never on a laptop.
5. Wrong network. A broadcast does not cross a VLAN, a guest Wi-Fi, a client-isolated network or, on some mesh systems, a different node. Check that the sender and the machine share a segment — same switch, off the guest network.
6. A BIOS power setting. ErP Ready, EuP 2013, deep sleep, or a mode that cuts the standby rail. Check the BIOS's power page with all of those off and Wake on LAN on — and take the right address: getmac /v, the Ethernet row, never a virtual adapter's.
7. The box woke and you could not get in, or it went back to sleep under you. Check the machine's settings on the dashboard: the Connect section reads SSH: listening on 22, or names the port sshd_config moved it to. A box whose daemon is not up says so and names the press — SSH: the SSH server is installed but not running. Start the sshd service and this row offers SSH…. — and one with nothing installed reads SSH: no SSH server found. Install openssh-server and this row offers SSH….; enable the service at boot while you are there, and remember that a firewall open to the local network and not to your mesh locks you out with the daemon running. Either way the row has a Set up SSH button that hands the whole job to the agent: open this page on the computer you will connect from, enter a code from your authenticator app, and press Set up SSH — the box’s own agent installs the login service, starts it, opens the machine’s own firewall for it, adds the key that computer made and turns password sign-in off. Two-factor sign-in has to be on for your account: the press hands out a shell. Then check the chip: SSH session idle means the session showed nothing for ten minutes and the meter's end was free to act — start the job before you walk away, or hold the box with Keep awake… on Plus and Pro.