I have Apple Remote Desktop on my MacBook Pro. It is in use it for my headless MacMini that runs Monterey. I would like to use ARD to go in and administrate the MacMini via Personal Hotspot on my iPhone. I have configured NAT on my AirPort and have already done a test to confirm that it works. The user that I use to logon via ARD has a 30+ long password. To be on the cautious side, I will only enable the NAT when I am out traveling for some weeks.
I am really only concerned with the security aspect. Is it safe to open up the ports for ARD?
ARD is, for the most part, an implementation of VNC. Which is why you can use a VNC client on a non-Apple computer to access a Mac whose screen is shared with ARD.
ARD version 2 has only minimal encryption (passwords, mouse events and keystrokes, but not the video image or file transfers). Which means you have no effective security unless your session is tunneled through a VPN.
ARD version 3 (introduced in 2006) will optionally let you configure 128-bit AES encryption for the entire session - equivalent to what SSH typically uses. This could be used via simple port forwarding, although you may still prefer to use a VPN to access it (with or without ARDâs own encryption).
If youâre willing to pay the $79 price for an ARD server, Iâd be OK using it. Just make sure to always keep it up to date and enable as much encryption as you can in order to keep the connection secure.
Whatâs built-in to macOS is the screen-sharing feature. And you donât need a special client either. If you can access the Mac on your LAN, you can open the Mac and start a screen sharing session from it (I do this all the time to access my mini server from my Air).
If you know the IP address or its hostname, you can also tell your Mac to establish a VNC connection to it. From the Finder, select Go â Connect to Server (CMD-K), and then enter a URL of the form vnc://ipaddress:port. I routinely do this to access a VNC server running on my Linux PC. Since ARD is based on VNC, it should work there as well.
But the $80 ARD software is more than that. From its product page, some of the features beyond screen sharing include:
Software Distribution
Copy and install software on remote Mac system
Configure a Task Server to assist with package installations on offline computers
Remote Assistance
Observe and control Macs
Prevent end users from viewing the screen while you remotely control their system (âCurtain Modeâ)
Remote administration
Remotely lock screens, sleep, wake, restart and shutdown Macs
Asset management
Remote Spotlight search
Collect reports on Mac hardware attribtues
See reports on user logins and application use
Use a Task Server to assemble inventory reports, including from mobile devices not on the network
Automation
Integration with Automator
This is clearly meant as an Enterprise network management tool, not just a remote access server, despite the name.
I did this many years ago. I always tunneled all my shared screen stuff through SSH. I wanted to be able to rely on known security rather than expecting certain versions of screen sharing (I admit I never understood the interfacing between ARD and VNC). It does require a fixed IP or at least you have to have some other means of determining what your current IP is remotely (like DNSUpdate daemon or so) ahead of time (as @Shamino says that used to be handled by BtmM). On a Mac all of this is rather trivial, on an iPhone Iâm not sure about setting up the SSH tunnel. Thereâs bound to be apps that would let you do that. I seem to recall thereâs no simple shell allowed per Apple guidelines though so that you canât just start doing ssh user@Mac -L 5900:IP:5900 or whatever.
I use VNC to remotely access my home server but have a firewall rule which uses the specific IP address Iâm accessing to and from. Any other addresses are denied. If you can do this I would think it relatively safe, especially if you only open it as required.
I think my area for concern would be the Airport itself. Apple discontinued the AIrport team in 2016 and stopped selling them in 2018 so thatâs a number of years since theyâve seen security updates. Iâm not saying thereâs known issues but I would be somewhat nervous using a device which is potentially 6 years without security patches.
Iâm familiar with the features of ARD as have had to use it at various times over the years â as you say, itâs more than a screen sharing client.
Whatâs built in is more than a screen-sharing feature. The ARD server thatâs built-in to MacOS provides everything necessary for the $80 ARD client to do all the system management you listed above. MacOS also includes the free Screen Sharing client that can connect to both VNC servers and Appleâs built-in ARD servers for slightly enhanced screen sharing (eg clipboard sharing, drag-and-drop). But to access the full ARD feature set you have to pay for the client app on the App Store.
You can subscribe to a dynamic DNS service if your IP address changes too frequently for manual management to be practical.
Another way is to write some script that periodically gets your external IP address and updates a file on a cloud server (e.g. iCloud Drive or MS OneDrive) with that address. So you can access the cloud file in order to get the address.
Yeah, thatâs exactly the DNSUpdate daemon I mentioned. There used to be free services, but these days youâre going to pay a couple bucks a month for that. Back to my Mac used to provide that for free, but these days, you either buy it or BYO via some hack like you mention.
Screens Connect provides shared session setup information so that, along with Screens 4, the long-gone Back to My Mac is reasonably well emulated. As part of configuration, encrypted (ssh) connections may be set as mandatory. NAT can be automatic or manually configured, mainly dependent on the router used by the target (shared) machine.
I have used the dynamic DNS service provided by Dynu https://www.dynu.com/en-US/DynamicDNS for a year now. There is a free option if you do not need a spesific DNS name. On my MacMini I have a client application that checks which IP address my internet provider has given me. Dynu IP Update Client checks with an interval of 30 to 45 minutes if there is any change. The client updates the Dynu DNS server. Many routers have support for this, then you do not need the Dynu IP Update Client.
I will test ssh tunneling with Remote Desktop tomorrow and report here.
Apple Remote Desktop via ssh tunnel did work. As some have said in this thread, you can use VNC instead of ARD if control is the only thing you need. Search for âScreen Sharing.appâ on your mac. It is tucked away in Library/CoreServices.
On AirPort, I have made a DHCP reservation for the MacMini using the Ethernet ID. This makes sure that the IP address of the MacMini does not change. Also, I have configured a NAT rule that directs port 22 on the router to my MacMini.
I updated ssh authorized_keys file on the MacMini with the content of id_rsa.pub from the MacBook Pro. This makes it possible to set up the ssh tunnel without passwords.
On the MacBook Pro I have made an Automator script with âRun Shell Scriptâ action with this one-liner âssh -L 13283:localhost:3283 -L 15900:localhost:5900 -f user@xxx.somedynamicdns.com sleep 60â I use the dynamic DNS service provided by Dynu see my post above.
In ARD I have added an entry in my list of macs to control. The address configured to localhost and the ports are 13283 and 15900. I have configured ARD to start a control session when I double click presets.
To control the MacMini, I connect my MacBook Pro to internet via Personal Hotspot on my iPhone. Start the automater script to set up the ssh tunnel and double click the Remote Desktop preset.
The reason I use Apple Remote Desktop is that I have used it in my daily work for many years.
I have not had time to test more than basic control. This note skips some details, feel free to ask for clarification.
It is in different locations on different macOS release. On my Big Sur system, it is located in /System/Library/CoreServices/Applications.
In general, however, you shouldnât need to run these services directly.
To access a Mac that is sharing its screen on your LAN, from the Finder, select Go â Network (or type CMD-SHIFT-K) to open the network browser. You should see the computer there. Double-click on it to view its file shares (if there are any) and then click the âShare ScreenâŚâ in the upper-right corner of the window to initiate your screen sharing session.
For a non-Mac device or a computer not on your LAN (so Bonjour canât discover it), you can manually provide a URL for it.
Activate the Finder and select Go â Connect to Server⌠(or type CMD-K). Then enter a URL of the form:
vnc://hostname:port/
For a screen shared by macOS screen sharing, you probably want to use port 5900. (e.g. vnc://hostname:5900/)
For a screen shared by some other VNC client (e.g. those typically made available by Linux systems), add 5900 to the screen number. For example, vnc://linuxhost:5901 for screen :1 running on âlinuxhostâ.
Iâve found that when doing screen sharing to another Mac itâs sufficient to simply use vnc://hostname and not bother with the port. Maybe there are edge cases where this doesnât work, but itâs worth a first try. You can also add it as a favourite in the Connect to Server dialogue so itâs easy to select in the future.
One other trick: if you open Safari and type in the URL for the VNC connection (for example, to my Mac mini) without hitting enter:
vnc://mac-mini.local
There will be a small globe icon to the left of the URL in the address bar. You can drag that icon to the desktop, or the right side of the dock (which is what I have done) to create a quick single-click way to open screen sharing to that host.
The VNC port number corresponds to the screen number.
When you have a VNC server that is mirroring the system console, it is commonly screen 0 and therefore port 5900. The fact that Apple is using it by default makes sense, because screen sharing does just that - it can even share the login screen. Itâs nice that Apple is defaulting to that port number for their VNC client.
When you use VNC to create additional network-only desktops (as I frequently do on my Linux PCs), then the first one is screen 1 (port 5901), the second is screen 2, etc.