MacInTouch Amazon link...
Channels
Other
A blast from the past...
I recall reading something many years ago which stated an 'unprotected' Windows machine was vulnerable on the web within 4 minutes. It wouldn't surprise me if it's less than that now.

If I switch on SSH to our Synology, I will have rejected login attempts within the hour. With our FTP server, we get attempts every few minutes - our blocked IP list is huge. You can just watch the logs expanding before your eyes with all the password guesses.

Here are some tips for the uninitiated (which really falls under common sense): Don't ever use 'password', '1234', 'qwerty' or 'xxxx' as a password. Don't use 'admin' for a username. For whatever reason 'slade777' and 'flow3r7' feature prominently as password guesses in our logs.

Also don't have the password and username the same, or the password the same as the domain name - these are very common attempts from people trying to password guess us.

Finally, if you don't need to have your machines exposed to the outside world, don't expose them.
 


Ric Ford

MacInTouch
If I switch on SSH to our Synology, I will have rejected login attempts within the hour. With our FTP server, we get attempts every few minutes - our blocked IP list is huge. You can just watch the logs expanding before your eyes with all the password guesses.
I wonder if switching to non-standard port numbers might help cut that down some.
 


Will this work? On your Mac create a new user for each remote Mac you'll access. Log the user in and enter their Apple ID. Then use BtMM. This requires diligence not to install any of that user's apps onto your Mac.
A big downside is needing to know and storing the remote user's Apple ID password.
Yes, it works, Sam, and has for years. But, no such luck for remote (WAN) access using BTMM in Mojave. (Local BTMM desktop sharing without such folderol seems to still work using Bonjour on a shared local network (LAN)).

And, yes, it can be awkward or painful at times. It really depends on the trust relationship between you and your client/friend/relative. And, in some cases, it is better not to know another's Apple ID credentials {explanation of liability considerations omitted}.
 


I wonder if switching to non-standard port numbers might help cut that down some.
The Synology DSM includes a thorough "Security Advisor" that suggests changing default ports. Easy to do. It also recommends auto-blocking repeated failed log in attempts, and blocking of IP ranges to which a user doesn't want NAS exposed (blocking by entire countries is pretty easy).

I blocked all countries except the USA. Oops. Seems Synology servers (at least some of them) are in the UK, which may be why the in-NAS help system ceased working until I enabled connections from UK.
 


I wonder if switching to non-standard port numbers might help cut that down some.
I'm sure it would. We very rarely turn on SSH so it hasn't been an issue for us - I was just pointing out how common SSH hack attempts are.
The Synology DSM includes a thorough "Security Advisor" that suggests changing default ports. Easy to do. It also recommends auto-blocking repeated failed log in attempts, and blocking of IP ranges to which a user doesn't want NAS exposed (blocking by entire countries is pretty easy).
Yes, the auto-blocking works well, and it's trivial to change ports. We have a nice green tick from the Security Advisor.
 


I wonder if switching to non-standard port numbers might help cut that down some.
I ran the firewall for a large corporation many years ago. I had to set up access for PCAnywhere (I think it was) and its usual ports were hit every day. I picked other quite obscure ports for the application, and those ports never got attacked - except for those idiots that tried to log into all 65535 ports in sequence.

Security through obscurity is not reliable, but it sure helps.
 


Ric Ford

MacInTouch
I look forward to your documentation of installation, configuration, and results.
OK, here's an update....

After many hours and adventures with remote access software experiments, I ran out of time and needed to just get something going.
  1. I built an up-to-date Mac system on an external, bus-powered FireWire drive (Oyen Digital Mini Pro case, I believe). I set it up with FileVault 2. It has a new macOS 10.12 system and a few critical apps (e.g. Carbon Copy Cloner).
  2. I copied a collection of remote control software into /Users/Shared, including TeamViewer installer, Screens apps, Jump software and Chrome Remote Desktop links
  3. I set up an admin account for me and an account for the non-technical user, making changes to Apple's defaults for privacy and usability - in System Preferences, Safari preferences, Finder preferences, etc.
  4. I configured the user account with a few logins and passwords for email, iCloud, etc. (hence the FileVault 2 configuration).
  5. I mirrored this system to a second partition on the same drive, using Carbon Copy Cloner. (I also have backups on my own drives.)
  6. (There's an additional partition with a virgin macOS 10.12 system, not yet booted, in case we wanted to start from scratch, but this is unlikely.)
  7. I tested as much as I could locally, booting the non-virgin partitions, checking that email worked, testing a local "remote" connection, etc.
  8. I packed up the drive and FireWire cable and mailed it across the country. (It was light, so that wasn't very expensive.) I was careful to specify that the drive needed a clean, flat, hard surface to sit on - not a stack of papers or anything like that.
  9. I scheduled a session with the user after the drive arrived and wrote out a checklist of what we needed to do and what the goals and options were. This was broken into phases with the most critical things first and more complicated things later, which we could delay doing.
  10. We shut down the computer and got the FireWire cable connected to the drive and the iMac FireWire port.
  11. She powered up the drive while holding the Option key. But the FireWire drive failed to show up (though its light was on). Uh oh. The wireless mouse also didn't work.
  12. I had her do a hard shutdown of the computer, find a wired mouse and attach it.
  13. We tried again. After a few misses with the Option key, we got the FireWire drive to show up with my system build. The boot process created confusion by prompting for a network, which led to a real runaround that finally resulted in me concluding that she had an Ethernet wired connection to the cable router.
  14. She finally got logged in, and we eventually determined that she could access the Internet via Safari and Mail.
  15. It was helpful for me to have booted a copy of the same system here, so I could see the same things she was seeing. I talked her through setting up an additional email account in System Preferences > Internet Accounts.
  16. Flushed with success, I had her launch ScreensXpress Connect and read me the screensxpress://____ URL, which I then typed into a web browser, which launched Screens on my Mac and, miracle of miracles, I managed to connect to her computer, and it wasn't even too slow. (I do not like some things about Screens, but it seemed like the least intrusive, simplest option for the moment.)
  17. From here, we needed Apple Pages and went to the App Store, but the App Store complained about her account - for a free download.
  18. This forced her into some nasty hoop jumping: Super-confusingly, Apple needed a different password for the Gmail address that's her Apple ID instead of the Gmail password for that Gmail address. <flame>This is an extremely user-hostile, confusing way to do things, which constantly messes up people I support, and the current "geniuses" at Apple could surely do it better, if only their "genius" were more about user interface design than profit-making.</flame>
  19. Past that, Apple forced multiple consecutive logins with the same Apple ID and password, which is stupid and confusing.
  20. We finally were able to determine, then, that the credit card info had changed. She was willing to enter updated credit card information and did so.
  21. After all this, we could finally download the free Pages app. Joy!
  22. But... somewhere in here, I lost the ability to click things with the mouse on her computer via Screens, though I could still do things with the keyboard. This was quite frustrating, and I wasn't able to solve the problem before we finally needed to call it quits. (I could observe and move the cursor but not click with the mouse, even after trying some workarounds.)
  23. Before quitting, I had her do a backup with Carbon Copy Cloner of her updated system.
So, she's happy with a new (not very fast) Mac system (on an external hard drive), and she can switch back to her old system easily by rebooting. (Integrating the two will come later.)

I was successful in controlling the remote Mac, which was great until Screens half-stopped working. So, there's more work ahead of me there, and the Screens trial period ends tomorrow. I'm conflicted about whether to buy it or not....
 


Thanks for summarizing your steps on this project. What an amazing odyssey. Glad you were ultimately successful. I'm confused about one thing, though.
This forced her into some nasty hoop jumping: Super-confusingly, Apple needed a different password for the Gmail address that's her Apple ID instead of the Gmail password for that Gmail address.....
Let's say I have an email address at Yahoo and I want to buy something from Amazon, so I create an account at Amazon using my Yahoo email address and a different password. When I sign in to Amazon, I use my Yahoo email address along with the password for my Amazon account. It seems that Apple is following a standard practice here.
Past that, Apple forced multiple consecutive logins with the same Apple ID and password, which is stupid and confusing.
I have run into this before. I did not find a definitive reason for it, but my assumption was that each app that was being updated/re-downloaded from the App Store needed to be individually authorized with the AppleID & password. Completely agree that it's a confusing situation, and a clear explanation would be helpful.
 


Ric Ford

MacInTouch
... Let's say I have an email address at Yahoo and I want to buy something from Amazon, so I create an account at Amazon using my Yahoo email address and a different password. When I sign in to Amazon, I use my Yahoo email address along with the password for my Amazon account. It seems that Apple is following a standard practice here.
I don't care whether it's "standard practice" or not, it's a fundamentally confusing and dysfunctional way to do things that constantly trips up the people I support, who end up typing critically important and sensitive passwords all over the wrong places.

Just think about this for a moment... with this dysfunctional user interface design, Apple is getting people - many, many people - to type their Google passwords into Apple servers (by 'accident'). Does Apple save incorrect passwords at all? You know, for security purposes and stuff?
I have run into this before. I did not find a definitive reason for it, but my assumption was that each app that was being updated/re-downloaded from the App Store needed to be individually authorized with the AppleID & password. Completely agree that it's a confusing situation, and a clear explanation would be helpful.
Nope, in our case, it was one single, simple app: Pages.

The problem is that Apple has multiple security realms, and you have to jump through hoops for each realm, along an extremely confusing maze of a path, but Apple doesn't show you what realms you're facing as it's forcing you to jump through all these hoops.
 


I don't care whether it's "standard practice" or not, it's a fundamentally confusing and dysfunctional way to do things that constantly trips up the people I support, who end up typing critically important and sensitive passwords all over the wrong places.
Just think about this for a moment... with this dysfunctional user interface design, Apple is getting people - many, many people - to type their Google passwords into Apple servers (by 'accident'). Does Apple save incorrect passwords at all? You know, for security purposes and stuff?
...
Nope, in our case, it was one single, simple app: Pages.
The problem is that Apple has multiple security realms, and you have to jump through hoops for each realm, along an extremely confusing maze of a path, but Apple doesn't show you what realms you're facing as it's forcing you to jump through all these hoops.
There are many ways Apple can clean up their security and sign-in system. First, I would have an app that just manages the phone using most of the stuff they took out of iTunes. I thought it stupid to have iTunes as a disorganized catch-all mess that did not even follow the GUI Apple standard.

Second, have an app to manage the security with the option to assign and change and undo passwords for various 'realms', as you call it. What happens when two people get married and wish to merge their music accounts?

It is like Apple is worshiping simplicity in the OS like they worship thinness in the laptops. The simplicity in the OS results in a decision somewhere by the user which has global ramifications that are unknown to the user. Then when you realized the ramifications, it is at best difficult to undo.

It is getting bad enough that when you are making changes, you need to run Carbon Copy Cloner every time before you make a change so that you can revert back to before you made the change.

That is not simplicity. It is ok and often useful to have default settings, but let me change the default settings using an advanced button. A classic irritant to me is the inability to set Time Machine to make only hourly backups until the hard disk is full and then start throwing away the oldest hourly backup. (I only use Time Machine for recovering from accidents and for previous versions of files.)
 


After many hours and adventures with remote access software experiments, I ran out of time and needed to just get something going.
Yesterday, I was attempting to build a simple laptop system running High Sierra and with access to screen-sharing via a machine-specific Apple ID and Messages. After many hours of repeated attempts to get Messages to add an "iMessage" account (having already logged in with the Apple ID via the iCloud pref pane), I gave up, and resolved not to try to use an Apple-only screen-sharing approach in future. Along the way, Apple will sometimes ask for the Gmail password associated with the Apple ID's email/username, and at other times ask for the Apple ID password set up at account creation … but I had no success after repeated log-out/log-in cycles and other attempts to troubleshoot.

… the Screens trial period ends tomorrow. I'm conflicted about whether to buy it or not....
While my creative tutoring business is Mac/iOS-only, it's not possible for me to rely on Apple's current implementation of its overarching Apple ID framework — it is still a bizarre patchwork of user-hostile impediments! I'm jumping into Screens as a relief from all that! My 'mileage' may vary, but I hope it is at least no worse than the failed "native" approach!
 


OK, here's an update....
  1. This forced her into some nasty hoop jumping: Super-confusingly, Apple needed a different password for the Gmail address that's her Apple ID instead of the Gmail password for that Gmail address. <flame>This is an extremely user-hostile, confusing way to do things, which constantly messes up people I support, and the current "geniuses" at Apple could surely do it better, if only their "genius" were more about user interface design than profit-making.</flame>
Can I ask what the expectation is here? Apple has zero ways to know what the password assigned to this account is, at Google. The best you could hope for, really, would be some sort of OAUTH or the like in order for Google to authenticate the connection to allow access to Apple resources. That's just not going to happen.
 


Ric Ford

MacInTouch
Can I ask what the expectation is here? Apple has zero ways to know what the password assigned to this account is, at Google. The best you could hope for, really, would be some sort of OAUTH or the like in order for Google to authenticate the connection to allow access to Apple resources. That's just not going to happen.
No, that's not what I meant at all (despite the fact that a lot of people are typing their Google passwords into Apple servers... by accident.)

Let's simply use the MacInTouch Community forum as an example. You log in here with your name, "Marc Wilson", and enter a password for this forum. Straightforward and unconfusing. (Yes, you have the option of entering your email address in place of your name, but you aren't forced into doing that by an aggressive Apple refusal to give you any other, less confusing option.)

There are so many other ways to do this - very obvious ones, not to mention inventing something better - that I have to think Apple designers are incredibly stupid, totally don't care (or have a clue) about their customers, or have cynical ulterior motives (if not all three).
 


... Let's simply use the MacInTouch Community forum as an example. You log in here with your name, "Marc Wilson", and enter a password for this forum. Straightforward and unconfusing. ...
Most people I support who have their own Apple ID are confused because their Apple ID is their email address on Google, Hotmail, Yahoo, et al. They keep entering their Google, et al. password when their Mac or iOS device asks for their Apple ID password. The reverse also happens, they enter their Apple ID password into Google, et al.
 


I followed good advice from MacInTouch and purchased Screens 4 with great success - however, just tried to update to V4.6 and received the advice posted below. I have rebooted in Mojave and also High Sierra, getting the same response. Any help/suggestions would be much appreciated.

(Screens is located in my Applications folder at the root level, along with all my apps.)
Screens can’t be updated when it’s running from a read-only volume like a disk image or an optical drive. Move Screens to Applications folder using Finder, relaunch it from there, and try again.
 


I followed good advice from MacInTouch and purchased Screens 4 with great success - however, just tried to update to V4.6 and received the advice posted below. I have rebooted in Mojave and also High Sierra, getting the same response. Any help/suggestions would be much appreciated.

(Screens is located in my Applications folder at the root level, along with all my apps.)
Screens can’t be updated when it’s running from a read-only volume like a disk image or an optical drive. Move Screens to Applications folder using Finder, relaunch it from there, and try again.
You may need to take two additional steps: First, move Screens out of the Applications folder (hold down the "Command" key while dragging it to, for example, the Desktop. Then move it back into the Applications folder using Finder.

The reason is that when you download an application, its "quarantine" flag is set, and certain operations aren't permitted. Finder "knows" when you move or copy an application into the Applications folder, and removes the quarantine bit in the new copy when you do that. Other ways of moving or copying into the Application folder don't do that - for example, Terminal's "cp" and "mv" commands and some Finder substitutes (for example, old versions of PathFinder).

It is possible that won't work, either. In that case, you can download Screens 4.6 directly from the publisher's website and copy that into the Applications folder using Finder (replacing the older version that is there now). That's necessary if the existing copy of Screens in /Applications has a very old version of the software that handles updates (which is probably Sparkle Updater).

For either of these you will be asked for a computer administrator's username/password.

A third way of fixing this is with Terminal:
  1. Quit the application.
  2. Run in Terminal, all on one line:
    xattr -dr com.apple.quarantine /Applications/Screens.app
  3. Re-launch the application
(Substitute the actual name in /Applications if it isn't "Screens". This may not work unless you are logged in as a computer administrator.)

Source: https://github.com/sparkle-project/Sparkle/issues/936 and several duplicate GitHub Issues.
 



I support multiple non-technical people using iPads, and I can't stand doing it anymore, as Apple has made it more and more difficult by constantly changing and complicating the user interface, dumping unwanted stuff into the device, making remote access virtually impossible, creating nightmarish security changes, update failures, demands you can't deny, etc. Bottom line: I will no longer recommend an iPad to anyone I have to support.
It's way too expensive but I think this product works to remotely view and control iOS devices.
LogMeIn said:
 



Yesterday I was faced with a 100 mile round-trip to our second office to diagnose why files we had previously been able to send encrypted through Google Drive weren't working, or quickly find a workable remote desktop solution.

What last worked for us was Google's Chrome Remote Desktop (GCRD). We've discussed before whether it is private from Google, and from what I've been able to tell, it is, but even after that, I had to set aside my continuing reservations about Google's increasing and often invisible surveillance.

That last time I tried to connect through GCRD, it just failed, where it had previously been straightforward and easy. I'm using Google Chrome on Linux in one office; the other is Google Chrome on Mac. Both computers are logged into our business Google Suite Gmail accounts, but neither browser is logged into Google for "browser sync."

It did help this time that both of us have iPads. With some difficulty, the remote user was able to aim the iPad at her screen and show me how her Chrome was configured.

In both locations I've installed the uBlock Origin, uBlock Extras, and EFF Privacy Badger Extensions. When GCRD seemed to be trying to connect, but just offered the equivalent of a "spinning beachball," we turned off all extensions in both browsers, re-initiated the connection request, and it worked promptly.

One other heads-up: Both systems have dual monitors. It used to work with mirroring enabled on the "help me" side, but this time we just turned off both secondary monitors (power and OS Display settings). You'll want to do that before trying to connect, though setting the "helped" side to mirroring might work. On my "supporting" end, it was necessary to disable my secondary monitor to keep the remote display from scaling at minuscule.

I've been thinking of trying the Apple way between two Macs over iMessage but wonder if Little Snitch would have to be off? We also don't log our Macs into iCloud. Anyone have insight into how that works currently? Does it work in Sierra? The Apple Support link below only has pages for Mojave and High Sierra.

 


Yesterday I was faced with a 100 mile round-trip to our second office to diagnose why files we had previously been able to send encrypted through Google Drive weren't working, or quickly find a workable remote desktop solution.
What last worked for us was Google's Chrome Remote Desktop (GCRD). We've discussed before whether it is private from Google, and from what I've been able to tell, it is, but even after that, I had to set aside my continuing reservations about Google's increasing and often invisible surveillance.
That last time I tried to connect through GCRD, it just failed, where it had previously been straightforward and easy. I'm using Google Chrome on Linux in one office; the other is Google Chrome on Mac. Both computers are logged into our business Google Suite Gmail accounts, but neither browser is logged into Google for "browser sync."

It did help this time that both of us have iPads. With some difficulty, the remote user was able to aim the iPad at her screen and show me how her Chrome was configured.

In both locations I've installed the uBlock Origin, uBlock Extras, and EFF Privacy Badger Extensions. When GCRD seemed to be trying to connect, but just offered the equivalent of a "spinning beachball," we turned off all extensions in both browsers, re-initiated the connection request, and it worked promptly.

One other heads-up: Both systems have dual monitors. It used to work with mirroring enabled on the "help me" side, but this time we just turned off both secondary monitors (power and OS Display settings). You'll want to do that before trying to connect, though setting the "helped" side to mirroring might work. On my "supporting" end, it was necessary to disable my secondary monitor to keep the remote display from scaling at minuscule.

I've been thinking of trying the Apple way between two Macs over iMessage but wonder if Little Snitch would have to be off? We also don't log our Macs into iCloud. Anyone have insight into how that works currently? Does it work in Sierra? The Apple Support link below only has pages for Mojave and High Sierra.

You might look into Screens 4. It does require IPv4 port forwarding but can connect directly using IPv6. The online instructions can be characterized as somewhat "confusing". your milage may vary.
 


You might look into Screens 4. It does require IPv4 port forwarding but can connect directly using IPv6. The online instructions can be characterized as somewhat "confusing". your milage may vary.
Thanks, James, I checked out the Screens online info. I like the developers' statements they don't use or believe in cross-site tracking, and that connections established using their software don't travel through their servers. The business use license of $29.95 is reasonable. I have to agree its setup instructions are "somewhat" (or more) confusing.

In trying to verify my past research showing Google Chrome Remote Desktop (GCRD) is secure and private, the most I could find is:
Support Google Chrome said:
Access another computer with Chrome Remote Desktop
For your security, all remote desktop sessions are fully encrypted.
Google previously assured us that "no one can see your data, not even Google." The phrase seems to have been removed. That desktop sessions are fully encrypted sounds good, but that isn't assurance of security and privacy from Google in GCRD sessions. It would be really nice to have a more detailed and technical description of how it works in 2019. It's also now much more a web interface, as Google has been eliminating the Chrome Web Store.

I launched the Chrome Remote Desktop web page version and found no mentions security, privacy, or Google's ability or non-ability to monitor traffic.
 


I am using a Mac Mini Late 2014, running OS X 10.11.6.

Frequently, I cannot connect to this Mac, either by VNC outside our network, or VNC inside our network (Screen Sharing). At the same time, the monitor goes blank and returns a message that HDMI cannot be found.

When this happens, the server still runs fine, serving files, sending mail, doing whatever else it does. Only connecting to it is dead until a reboot.

Ideas anyone? Thanks
 


I am using a Mac Mini Late 2014, running OS X 10.11.6. Frequently, I cannot connect to this Mac, either by VNC outside our network, or VNC inside our network (Screen Sharing). At the same time, the monitor goes blank and returns a message that HDMI cannot be found. When this happens, the server still runs fine, serving files, sending mail, doing whatever else it does. Only connecting to it is dead until a reboot. Ideas anyone? Thanks
My headless Mac Mini 2014 is currently on good behavior, but it isn't always. As others have mentioned, I have found it more reliable to connect Screen Sharing via the IP address than the name of the device.

If yours is also headless, I can recommend something like this to speed up the remote display:

It fools the Mini into thinking a display is attached, and kicks in the GPU. With the CPU no longer doing all the heavy lifting, Screen-Sharing is much more responsive. There are others that attach via Thunderbolt, but I like this one that uses the HDMI port, which I would otherwise have no use for.

Other than those tweaks, sometimes it just seems like voodoo here, too.
 


Ric Ford

MacInTouch
Here's a tutorial on Mac "screen sharing" (remote access) from OWC:
Rocket Yard blog said:
Use Screen Sharing to Troubleshoot a Mac
Screen sharing is the process of allowing someone else to see what’s on your screen; open, close, and move files and windows around; open apps; and restart the Mac. Essentially, screen sharing allows someone to be virtually seated next to you, looking over your shoulder, or even taking control of your keyboard, mouse, or trackpad.
 


Here's a tutorial on Mac "screen sharing" (remote access) from OWC:
After I updated to High Sierra I found that Timbuktu would no longer work well over VPN. File sharing through Exchange still works fine, but attempting to control the remote computer would be laggy and then stall after a minute with the remote Mac becoming unresponsive. This could be something with how our network techs have our network set up, but they had no solution for it. Timbuktu still works OK for both file sharing and screen sharing when on the local network.

I started using the built-in Screen Sharing, and it works very well, even over VPN. The only issue I've found is that cut and paste does not play well with the only Java app I use, SQL Developer, when I attempt to cut and paste on the remote Mac.

The app ScreenSharingMenulet (available on the Mac App Store) is a nice addition that puts an item in the menubar to easily access remote computers.
 


After I updated to High Sierra I found that Timbuktu would no longer work well over VPN. File sharing through Exchange still works fine, but attempting to control the remote computer would be laggy and then stall after a minute with the remote Mac becoming unresponsive. This could be something with how our network techs have our network set up, but they had no solution for it. Timbuktu still works OK for both file sharing and screen sharing when on the local network.

I started using the built-in Screen Sharing, and it works very well, even over VPN. The only issue I've found is that cut and paste does not play well with the only Java app I use, SQL Developer, when I attempt to cut and paste on the remote Mac.

The app ScreenSharingMenulet (available on the Mac App Store) is a nice addition that puts an item in the menubar to easily access remote computers.
Did you set the connection color resolution to minimum? This has always been useful for using Timbuktu over slower connections.
 


If I have an iMac at the office, and I am using a laptop at home, how can I make the iMac answer my remote laptop's request to share the office iMac? This would be an easy way to access my server from a remote location.

I am familiar with screen sharing, as I use it often to help a member of my family. Screen sharing that I am using requires a person at the receiving end to press a button to accept the connection.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts