Mac OSX - Restart VNC Server over SSH

mac_restart_vnc_over_ssh.md

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

Additional Commands from Apple Website:

• Original Apple Support Site Link
• Google Cache Link
• Web Archive Link

Sample commands

The commands in this article work with Apple Remote Desktop 3.2 and later.

Restart the ARD Agent and helper:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

Turn on Remote Desktop Sharing, allow access for all users, and enable the menu extra:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -all -clientopts -setmenuextra -menuextra yes

Turn on Remote Desktop Sharing, allow access for specified users:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers

You must use the -configure, -access, and -privs options in a separate command to specify the set of users and their access privileges. For example, this command is for users with the short names "teacher" and “student." It gives them access to observe (but not control) the computer, and to send text messages:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users teacher,student -access -on -privs -ControlObserve -ObserveOnly -TextMessages

Unlike other kickstart options, you can’t combine the allowAccessFor options with other kickstart options. You must use it as in the last two samples above. You might have to call kickstart more than once to finish a computer’s setup. Remove access privileges for specified users ("student" in this example):

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users student -access -off

Disable ARD Agent and remove access privileges for all users:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off

@mistal-distal hey it looks like that last command snippet is cut off in the middle.

@webknjaz

Good catch thanks. Full command is

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off

Dont have time to login and fix now this isnt a priority for me

##mistal-distal## ~ reminder 1 week ~ update original doc

So the commands about didn't help me right away post updating to macOS 13/14 (would probably break with 12 too). VNC was working but streaming a black screen over network.

This was happening on the boxes hosted via MacStadium and when they toggled it via the local keyboard, it started working again.

I think the problem was with Full Disk Access (it's under Privacy & Security in modern OS versions).

I was using Ansible to run the update scripts, which relies on the presence of Python. macOS 12.3 removed Python (2.7) from their distribution, with no replacement offered. So I provision it first, also via Ansible (ansible-playbook samdoran.macos.bootstrap -e target_hosts=macstadium-hostname).
Once it's there, Ansible is usable. But the Python binary is not the same as the one provided earlier. It's Python 3, for one. It's also in a different location.

The gotcha was that adding /usr/bin/python3 to Full Disk Access allowed Ansible modules that are executed by that interpreter to actually influence the system settings, including allowing screenshare.

That's my theory, at least. Posting it here for people landing on this page from Google search.

Glad to hear you got it working.

So for for mac 13/14 possibly 12 Ansible setups:

1. Install python 3
2. Allow full disk access to /usr/bin/python3

A little bit outside the scope for this original post but I enjoy hearing about the troubleshooting. Most of these repos/gists on my account are tongue in cheek in nature

Yeah, that's my best guess. I don't have a Mac at home to verify, and can't experiment too much on the remote boxes (we're running VMs for the Ansible Core CI there so it's not really acceptable). Maybe, if I manage to get one, I'll try to reproduce this to verify. The upgrade originated on MacOS X 10.15 so that's a difference of many versions in between, crossing that 12.3 boundary additionally. For a regular SSH session, I think, granting FDA to /bin/zsh while you still have VNC or local access, might do the trick.

This is not really spelled out anywhere on the internet so I wanted to make sure these findings don't get lost. Most people mass-managing macs would use MDM to set up FDA, but it's not doable for us since our use case is in between "a user is managing their one Mac with unrestricted access to the local session when needed" and "an IT department managing thousands of end-users' Macs".

Friendly reminder to rollback permissions slowly and see if it still works. Make if work, make it right, make it fast, make it secure.

Either that or after the configuration is finished rollback the FDA modifications entirely. Probably the easier/better choice in this scenario since it sounds session specific

That sounds pretty cool, so you're esentially using ansible as stand-in asset management, which has the added benefit of helping to configure with freedom of connectivity versus assuming ownership over the system and having it enrolled into something like an MDM in order to configure (which possibly brings a whole can of worms). Very neat.

Also lets you do highly customized one offs, and auth independently if its owned by someone else or needs indepedent credentials.

Yep, it's a good idea to undo FDA post-upgrade. Though, I'll postpone troubleshooting until I get a machine that I can crash w/o consequences :)

Some of the automation is built on top of this collection https://github.com/samdoran/ansible-collection-macos (maintained by a former colleague of mine who was in charge of the Ansible Core CI infra before me). I'm hoping to open up the playbooks for making macOS VMs / host upgrades at some point — the only reason they are in a private repo are historical and that it may contain some sensitive data in the Git tree that nobody audited...

@webknjaz

Fixed the original script.

Oh shit, you've got impressive work going man!Please excuse me for digging into your history. I've used cherrypy quite a bit in the past. I didn't realize you were a primary developer of ansible, that's sick!

Unless its a personal project you're working on, I'm surprised an org as large as redhat couldn't provide you with resources to test that :p That statement should be taken lightly/jokingly

I can't make any promises on this, but if you're able to wait I might be able to test it for you, if you'd like to work on it together. I have an old mac floating around that could use a bit of help with upgrading. I just have to find it first. I'd also like to get back into ansible, part of another effort I'm working on is slightly reinventing the wheel with regards to system management, and I think ansible has the right amount of customization through modules to achieve some of the more case specific needs.

Again I would need some time, I have more pressing priorities that need to be taken care of.

Let me know if that sounds interesting to you