Keep Your Mac Awake for SSH Sessions

Identify the host and the client first

The host is the Mac you log into. The client is the computer where you type the SSH connection command. Once you log in, commands entered in that remote shell run on the host. A fresh local Terminal tab still runs on the client.

For example, you might use a MacBook to inspect a job on a Mac mini. Keeping the MacBook awake does not configure the mini’s power settings. Conversely, an awake mini cannot keep the MacBook’s network connection alive after the laptop sleeps.

A locked screen, a dark display, and system sleep are different states. You can retain password protection while managing sleep; see our Mac sleep and screen-lock guide.

Check Remote Login while the host is available

If SSH already works, leave its access configuration alone. For a Mac you own or administer that needs initial setup, open System Settings → General → Sharing, open the information panel for Remote Login, and enable it. Choose the specific accounts allowed to connect. Copy the connection command shown in that panel and try it from the client while you can still reach the host locally.

Apple’s Remote Login instructions describe SSH access and account selection. The command has the form ssh username@hostname; use the actual account and address shown for your Mac. Full disk access is a separate permission, not a sleep-prevention switch.

Use an already configured, trusted network route. Enabling Remote Login does not by itself arrange access from another network. If the first connection fails while both Macs are awake, resolve the address, account, or network problem before changing sleep settings.

Give the host a temporary awake window

For a two-hour window, open Terminal locally on the host Mac before leaving it and run:

caffeinate -i -t 7200

Keep that Terminal session open. The command holds an idle-system-sleep request for 7,200 seconds, then releases it. It does not request a continuously lit display. Press Control-C in that window to end it early. The timer starts when you launch the command, not when someone connects.

For example, starting at 13:00 gives a window ending around 15:00. Connecting at 14:45 does not grant another two hours. Record the start and expected end beside your work plan.

For ongoing access on external power, Apple documents a power-setting alternative: on a MacBook, open Battery → Options and enable the setting that prevents automatic sleep on power when the display is off. On a desktop Mac, look under Energy. Options vary by model. Note the original value so you can restore it.

Use external power and leave a MacBook host’s lid open for this procedure. Neither setup is a promise of availability through a restart, a network outage, or closed-lid operation. Our closed-lid guide covers that separate case.

Protect a command or the client session

Inside an existing remote Mac shell, a command-scoped request can cover one utility. This harmless example waits for thirty seconds:

caffeinate -i /bin/sleep 30

The idle-sleep request ends with the utility. For real work, replace /bin/sleep 30 with the command and arguments you actually intend to run. Apple’s caffeinate manual documents both lifetime modes; a -t timeout is not used when a utility is supplied.

On a local Mac client, you can instead wrap its SSH process:

caffeinate -i ssh username@hostname

Replace the example login with yours. This requests that the client avoid idle sleep while that SSH process runs. It does not install an awake request on the host. See the complete caffeinate guide for other options.

Sleep prevention does not make a job independent of its terminal. Closing a window or losing SSH can affect work attached to that session. If a job must survive disconnection, use that job’s documented background or resume method, or a separately configured persistent session, and test recovery with a disposable task first. Do not treat an awake request as proof that a job survived.

Keepalive messages check a different problem

If the Macs remain awake but a quiet SSH connection becomes unresponsive, you can test client-side server-alive probes:

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 username@hostname

After thirty seconds without incoming data, the client requests a response through the encrypted connection. With three unanswered probes, it disconnects after approximately ninety seconds. This example makes failure detection more predictable; it is not a ninety-second session limit when the server continues replying.

OpenSSH documents these controls. They do not reconnect a lost session, repair Wi-Fi, or preserve a remote job. Keep the original error text and time so you can compare a connection failure with what the host was doing.

Verify on the right Mac before leaving

While the host’s timed request is running, use a second Terminal window on that host, or another authenticated shell on it, to run:

pmset -g assertions

Look in the process-owner entries for caffeinate and PreventUserIdleSystemSleep. Record its process ID. A summary value of 1 alone cannot tell you which app owns the request. Our sleep-assertion diagnostic guide shows how to read the owner and check its disappearance afterward.

Then make a short, repeatable observation: connect from the client, record the time, leave the host’s display to turn off normally, and run a harmless command such as date after your usual idle interval. This is a proposed check of your actual setup, not a guarantee about a longer unattended run. Test while local access remains possible.

Finish the session and check the result

Check the job’s own completion result before disconnecting: its exit status, saved output, or application log, as appropriate. An SSH prompt only proves the shell is responsive. Avoid starting a second copy of an uncertain job until you know whether the first is still running.

End your timed request early with Control-C if it is no longer needed, or allow its timer to expire. Confirm that its process-owner entry disappears; another app may still have an independent request. Restore any temporary power preference. Use exit to leave the remote shell; this ends your session but does not turn off the Mac’s Remote Login service.

Where Mouse Jiggler fits, and what we tested

Mouse Jiggler for Mac offers a separate Prevent Sleep While Active control for a Mac where the app is running. Its session conditions still matter. It does not configure SSH, monitor a remote job, or reconnect a lost session. Automatic clicks, scrolling, and key presses are unnecessary for this command-line workflow.

On November 2, 2026, we checked a four-second timed request and a four-second command-scoped request on macOS 27.0.1. In both, the caffeinate owner’s idle-sleep assertion appeared and disappeared after completion. We also checked that the local SSH client accepted the two server-alive values without making a connection. These were short local checks, not a two-hour SSH endurance test, a closed-lid test, or a remote job-recovery test. The cover is an editorial illustration.