Skip to main content

Why so hard?: Access OSX over SSH with non-admin account.

The Problem

I recently ran into an issue where my Raspberry Pi file share server fell over because of hardware currosion due to some unfortunate moisture exposure. In response, I had planned to replace the file share server with a Mac Mini that was available until I could get a replacement RPi. The service is basically SFTP and the users are responsible for having SFTP clients that meet their needs.

Since the team I am working with isn't large, I manually created the members as individual (non-admin) accounts in OSX and assigned each a password. After this, I tested my personal (admin) account with the SSH service and everything worked great. Next, I tested a non-admin account and it didn't work!

$ ssh joe@192.168.1.10
Password:
Connection closed by 192.168.1.10 port 22

Troubleshooting

I attempted to fix it by examining the system preferences of "Remote Login" and repeatably checking /etc/ssh/sshd_config. I attempted to locate the issue by running through the following commands in different situations.

To reload SSHd with its configurations, you can run:

sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

To stop the SSHd service (and allow it to automatically restart):

sudo launchctl stop com.openssh.sshd

Also, to examine the system service from command line, you can boost and examine the log output with something similar to:

sudo log config --mode "level:debug" --subsystem com.openssh.sshd
sudo log stream --level debug 2>&1 | tee /tmp/logs.out

After you perform the action you want to examine, stop the log stream process and grep or analyze the /tmp/logs.out file.

Note: To reset log level, run:

log config --mode "level:default" --subsystem com.openssh.sshd

All of this troubleshooting wasn't getting me anywhere. After no success and with it getting late in the day, I decided to sleep on it.

Solution

After waking in the morning, I found an Apple StackExchange question on the subject, Is it possible to access a Mac via SSH without administrator access?. There was an answer in that question page that led me to a Mac OSX Hints page, Use dseditgroup to allow users access to services (ssh, screen sharing, and more).

Here is where I found the magical formula. Assuming you have an admin account like say vinnie and a non-admin user account like say joe or a user group like say staff, you can allow joe:staff to access the OSX SSH service by running the following commands with admin access:

dseditgroup -o edit -n /Local/Default -u vinnie -p -a joe -t user com.apple.access_ssh
dseditgroup -o edit -n /Local/Default -u vinnie -p -a staff -t group com.apple.access_ssh

Screen Sharing is another such service that requires this kind of policy updating:

dseditgroup -o edit -n /Local/Default -u vinnie -p -a joe -t user com.apple.access_screensharing
dseditgroup -o edit -n /Local/Default -u vinnie -p -a staff -t group com.apple.access_screensharing

Rant

Now ... I'm happy that I found out the right command to get SSH to work on OSX and I hope to never have to learn yet another way to get this to work, but why is it this way? I am all for increasing security, but at the cost of usability? I figured there would be an option in the Security section of the System Preferences to all me to add users to these groups. But alas I found none. I only own the Mac Mini so I can run XCode builds of applications I generally support on other platforms. I personally can't stand OSX and iOS and this is just another notch on the list or reasons not to associate with these products.

When I think about it, another technology in Linux that drove folks to a similar madness was SELinux. SELinux in spirit was a great advancement in Linux kernel security, but it still to this day has a usability problem that has led to more inferior products like AppArmor. At least in the case of SELinux there was a permissive mode ... I doubt Apple would consider such things as useful.

Comments