Skip to content

Latest commit

 

History

History
380 lines (271 loc) · 11.8 KB

File metadata and controls

380 lines (271 loc) · 11.8 KB

Video 2: Preparing the Machine for Remote Use

Series: Setting Up Signet & OpenClaw, shown on a Mac Mini Runtime target: 12-15 minutes Tone: Plainspoken, reason-first, showing terminal throughout


INTRO

Before we install anything, we need remote access working and the machine behaving predictably.

A stock Mac Mini assumes somebody is nearby with a keyboard, a monitor, and the patience to click through surprises. A remotely managed machine needs the opposite. It needs to stay reachable when something goes sideways, avoid consumer nonsense, and, if it is going to be a dedicated always-on box, come back cleanly after a reboot or power loss.

That's what this video is for.

One framing note before we get lost in command blocks: in real life, I do not sit there manually typing every hardening command one by one on a fresh machine. Anything repetitive lives in a bootstrap or hardening script. I will link that script in the description. For the video, I want to show the decisions that matter, the kinds of changes the script is making, and the checks I use to confirm it actually worked.

And this is the most mac-specific video in the series. The hardening goals are the same on Linux, but the exact commands differ. You still want SSH enabled, sleep disabled if the machine is meant to stay up, remote access working, the firewall configured, and unnecessary desktop services out of the way. On macOS we do that with macOS-flavored tools.

One more important boundary before we start: a few steps in this video are only for a dedicated unattended machine you physically control. If this Mac is your daily driver, keep FileVault on, do not turn on auto-login, and just take the remote-access parts.

FIRST PASS ON THE MAC ITSELF

Before we SSH in, there is one very ordinary step that still has to happen on the machine itself.

Open System Settings, then go to General, then Sharing.

At minimum, turn on Remote Login. That is what enables SSH. If macOS asks which users are allowed, keep it tight. Add the user account you're actually going to administer the machine with.

Linux equivalent: enable and start sshd. Same result, different switch.

If you want a GUI fallback, also turn on Screen Sharing or Remote Management. We'll still configure remote desktop access more explicitly later, but it is worth making the basic sharing permissions correct in the UI first.

Linux equivalent: if you want a GUI fallback there too, use whatever remote desktop path you trust, usually VNC, xrdp, or some other remote-desktop layer. Same role, different tooling.

And if this Mac is going to live on your tailnet, this is also a good moment to install Tailscale and sign in. You can do the first setup over local LAN if you want, but once Tailscale is on the box, the remote story gets much cleaner.

Once those switches are in the right state, move back to your main workstation.

SSH IN

First, connect to the machine. I'm using Tailscale, so I can reach it by Tailscale IP or hostname.

ssh username@your-mac-mini-ip

If this is the first time connecting, accept the fingerprint.

Then get a quick read on the box so you know what you're working with.

sw_vers
sysctl hw.memsize
sysctl hw.ncpu

Nothing fancy here. I just like knowing the exact machine before I start changing it.

FILEVAULT, DEDICATED BOX ONLY

On a laptop, FileVault is the right default. On a dedicated unattended box, it can be a remote lockout waiting to happen.

If this is your personal machine, stop here and leave FileVault on. I am only talking about a box that lives in your space, stays put, and is meant to boot back into service without somebody standing next to it.

If the machine reboots after a power outage, a panic, or an update, FileVault stops everything at the pre-boot unlock screen. macOS has not loaded yet. No SSH. No Tailscale session. No rescue except physically walking over and typing the password.

So check the state first.

fdesetup status

If it says FileVault is on and this is truly a dedicated box, disable it. I do that from the bootstrap script linked in the description, because the real command uses the standard fdesetup disable -inputplist flow and includes credentials. That is exactly the kind of thing I do not want to freehand on camera.

Decryption happens in the background. The machine stays usable while it runs. You can check progress with fdesetup status until it finishes.

AUTO-LOGIN, ALSO DEDICATED BOX ONLY

This is the part that sounds wrong until you think about what the box is for.

On a personal machine, I would not tell you to enable auto-login. On a dedicated unattended box, I do, because user LaunchAgents, including things like Signet and Tailscale, do not fully come alive until a user session exists. If nobody ever logs in, your services can stay half-dead in annoying ways.

Same warning as FileVault. Do not do this on a laptop or daily driver.

On macOS, unattended boot means setting the autoLoginUser preference and creating /etc/kcpassword. I handle both of those in the bootstrap script linked in the description. I am not going to read an obfuscated password-writing one-liner out loud like that is normal human speech.

It is not elegant. It is also how unattended boot works on macOS.

And just to be explicit, auto-login will not work while FileVault is enabled. That's why we dealt with FileVault first.

POWER MANAGEMENT

Now we make sure the machine behaves like a server.

sudo pmset -a displaysleep 0 disksleep 0 sleep 0 \
  powernap 0 autorestart 1 networkoversleep 1

What matters here is simple:

  • sleep 0 means the box does not go to sleep.
  • autorestart 1 means it comes back after power loss.
  • networkoversleep 1 keeps the network side sane even with the display off.

Verify it.

pmset -g | grep -E 'sleep|autorestart|powernap'

Linux equivalent: same goal, but this usually lives in firmware power settings plus systemd-logind or your distro's sleep configuration instead of pmset.

FIREWALL

I want the built-in firewall on. I also want stealth mode on so the machine is less chatty on the network.

FW=/usr/libexec/ApplicationFirewall/socketfilterfw
sudo $FW --setglobalstate on
sudo $FW --setallowsigned on
sudo $FW --setstealthmode on

Then confirm it actually took.

sudo $FW --getglobalstate

SMB AND FILE SHARING

A lot of Macs ship with sharing features that make sense on a household machine and not much sense on a headless server.

First, remove existing share points. The important detail here is not to hardcode share names. macOS likes to use curly quotes in default names, which is a ridiculous thing to debug remotely.

sharing -l | grep "^name:" | sed 's/name:[[:space:]]*//' | \
  while read -r name; do
    sudo sharing -r "$name" 2>/dev/null && \
      echo "removed: $name" || echo "skip: $name"
  done

Then make sure guest access is off.

SMBPREF=/Library/Preferences/SystemConfiguration/com.apple.smb.server
sudo defaults write $SMBPREF AllowGuestAccess -bool false

DISABLING CONSUMER SERVICES

This is where the machine stops pretending it's somebody's living room computer.

I disable the services that add background churn and zero value on a server: Siri, Photos sync, News, Weather, Game Center, Home, Find My, and a few related helpers.

And to be clear, this is exactly the kind of thing I keep in the hardening script linked in the description. Nobody needs to cosplay as a deployment pipeline and read twenty launch service labels aloud if they already know what they want disabled.

The exact labels are in that script. The short version is Siri, Photos sync, News, Weather, Game Center, Home, Find My, and a few related helpers.

This stays SIP-safe, persists across reboots, and does not require you to start doing weird surgery on system files.

HOSTNAME AND SPOTLIGHT

Give the box a real name.

sudo scutil --set ComputerName "mac-mini-server"
sudo scutil --set HostName "mac-mini-server"
sudo scutil --set LocalHostName "mac-mini-server"

Then disable Spotlight indexing. On a server, I don't need the machine burning cycles so it can answer Finder searches nobody is making.

sudo mdutil -a -i off

SOFTWARE UPDATE BEHAVIOR

I still want the machine checking for updates. I do not want it deciding to install them on its own at a bad moment.

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate \
  AutomaticInstall -bool false

That gives you visibility without surprise reboots.

Linux equivalent: same principle. Let the box tell you updates exist, but do not let unattended reboots pick the schedule for you. The exact knob depends on the distro.

VISUAL EFFECTS

This part is optional, but I do it anyway.

A headless box does not need pretty animations, transparency, or extra GPU churn. If I ever remote into the GUI, I want it lean and fast.

defaults write com.apple.universalaccess reduceTransparency -bool true
defaults write com.apple.universalaccess reduceMotion -bool true
defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool false
defaults write com.apple.dock launchanim -bool false
defaults write com.apple.dock expose-animation-duration -float 0.1
defaults write NSGlobalDomain NSWindowResizeTime -float 0.001
killall Dock 2>/dev/null || true

SCREEN SHARING

Sometimes SSH is not enough. Sometimes you need to see the desktop.

The built-in ARD kickstart utility is the reliable way to enable screen sharing on modern macOS.

Again, this is script territory. I care that the machine ends up in the right state, not that I personally retype the whole incantation every time. I use the built-in ARD kickstart utility from the bootstrap script linked in the description to enable screen sharing and set the VNC password.

One important gotcha here: use -allowAccessFor -allUsers. Do not use -specifiedUsers. It leads to broken auth states that are an absolute waste of time to debug.

Once this is on, connect from another machine with any VNC client to the Tailscale IP on port 5900.

Linux equivalent: same story. SSH first, GUI fallback second.

SSH KEY AUTH

Now we get rid of password friction for normal remote work.

On your workstation, if you do not already have a key:

ssh-keygen -t ed25519

Then copy the public key over.

ssh-copy-id username@mac-mini-ip

Or do it manually.

cat ~/.ssh/id_ed25519.pub | ssh username@mac-mini-ip \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Test it.

ssh -o BatchMode=yes username@mac-mini-ip echo ok

If that prints ok, you're in good shape. You can disable password auth later if you want, but key auth working is the real milestone.

ADD IT TO SSH CONFIG

On your workstation, give yourself a short host alias so you stop typing full addresses.

# ~/.ssh/config
Host mac-mini
    HostName YOUR_TAILSCALE_IP
    User YOUR_USERNAME
    SetEnv TERM=xterm-256color

That SetEnv TERM line fixes a particularly stupid terminal issue with Kitty and tmux over SSH. Even if you are not on Kitty, it does no harm.

After that, ssh mac-mini is enough.

VERIFY

Run through the basics one more time.

pmset -g | grep -E 'sleep|autorestart'
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
sharing -l
launchctl print-disabled gui/$(id -u) | grep -c disabled
scutil --get ComputerName
mdutil -s /
defaults read com.apple.universalaccess reduceTransparency
defaults read com.apple.universalaccess reduceMotion

If all of that looks right, the machine is ready for the software side.

OUTRO

That's the hardening pass.

At this point the Mac Mini is boring in the way you want. It stays up, comes back after trouble, exposes less junk, and is actually pleasant to reach remotely. In the next video, we install the tools we need to work on it without fighting the machine every five minutes.