Friday, April 28, 2023

Allowing a Remote Computer to Access Your Mac


Turn on Remote Login to access your Mac from another computer using SSH (Secure Shell Protocol) or SFTP (SSH File Transfer Protocol).

This had been working for me for a long time, but at some point something happened to my TCC database and then rsync started failing:

rsync: opendir "/Users/mjt/Documents/C-Command/." failed: Operation not permitted (1)
rsync: failed to set times on "/Users/mjt/Documents/Code/Git": Operation not permitted (1)

This looked like a Full Disk Access problem, but the old solution of adding sshd and rsync to System Settings ‣ Privacy & Security ‣ Full Disk Access didn’t help.

The trick is that there’s now a separate Allow full disk access for remote users setting, but it’s under General ‣ Sharing instead of Privacy & Security ‣ Full Disk Access. And it’s now only visible if you click the little i button next to Remote Login. With this selected, you don’t need to give sshd Full Disk Access.

There is no corresopnding setting in the i next to File Sharing, so perhaps you still have to give smbd Full Disk Access manually.


4 Comments RSS · Twitter · Mastodon

Apple had remote access working, and it worked pretty well, even though the discovery of the feature was somewhat obscure. It had both file access and remote screen control. At some point Apple removed it and now an average user has to rely on some kind of VNC protocol via 3rd party solutions, slow, clumsy and outdated. Not even close to MS Remote Desktop.

It's a bit different story for developers or some other IT professionals, who can set up dynamic DNS, remote access and other useful services and even use them with CLI.

Even persistent local network share mounting is not that easy on a mac these days.

In other words the current situation is opposite of "It just works".

@Dmitri I’ve actually found that screen sharing over iMessage works pretty well now, whereas it used to always fail for me.

@Michael it works about ~80% of the time when I connect with other people.
Connecting to my own computers that are not on the same LAN using Apple screen share is much more problematic for me, so I use Jump for that now. And iMessage option is not good for file sharing in my experience. So I use Backblaze for files that are not in some cloud already.

All that worked really well with Apple's Remote Desktop when machines were logged in to iCloud (or maybe it was then).

Or you could just turn off SIP. Solves a myriad of silly problems like this one. I did find the setting, all the same, but this is basically why, hard as it is to ignore Apple's creeping iOSification and the potential implications for some future macOS without SIP disablement as a potential fix, I nonetheless disable SIP as pretty much the first thing I do on any Mac I intend to access over the network or that are expected to run any daemons that automate the system to any meaningful degree.

@Dmitri @Michael I think you mean BTMM? That gave you IPv6 ULAs and wide-area Bonjour, over which you could discover and run your file sharing and screen sharing services. A wonderful feat of technical engineering, whose abolition was a dark day for macOS IMNSHO. The person-to-person screen sharing accessible from Messages (and, indeed, manually from the Screen Sharing app, launched from Spotlight) is a subset, and requires acknowledgement from the far side, even if that is your own Apple ID. It also sets up a VoIP call, so is more akin to FaceTime (no audio from the session, sadly, just mic inputs). BTMM was more general-purpose than that, and was overlay mesh networking from Apple before that was cool. The first generation required UPnP/NAT-PMP from the router, so that it inevitably didn't always work (Screens has a utility that does similar); the second generation used contemporary NAT hole-punching techniques, but it was also more fragile and slower and most probably suffered from a somewhat less refined and robust implementation before it was cancelled altogether. Nowadays there are many alternatives (Zerotier, Tailscale, Nebula, Tinc, ...). I now use Cloudflare Zero Trust, which includes a tunnel for TCP/UDP traffic for designated subnets as an option with a trivially-installed daemon on any machine that connects from the inside; works fabulously well even behind a CGN, and doesn't require peer-to-peer connectivity but uses Cloudflare's network for transit. It's free for personal use, so check it out if you want a nice way to gain access to your networks or web apps with authentication and protection from Cloudflare (no connection, just a happy free user).

Leave a Comment