1. 31
  1. 6

    This has bitten me as well. I’ve learned the hard way that, as a rule, you should never modify any system file in macOS: that poses a security risk, as explained in the article.

    For SSH, a solution is to disable the system’s daemon (System Preferences > Sharing > Remote Login must be turned off). Then, copy/create sshd_config into your home (or somewhere you know it won’t be overwritten) and copy /System/Library/ssh.plist into /Library/LaunchDaemons. Edit the latter execute /usr/sbin/sshd with your own sshd_config. Load and bootstrap the launchd item, and leave in peace again. Until Apple breaks this workaround as well. So far, if I am not mistaken, /Library/LaunchDaemons is not reset on updates.

    Apple should provide a way to “hook” into some configuration files (e.g., it is possible with pf) to let users be able to configure them the way they want. And for SSH specifically, if Apple wants to seal the system, it should as well disable password authentication in SSH by default. Remote Login in System Preferences could be updated so that turning it on sets up or asks to set up public key authentication.

    1. 2

      I swear, I’m getting closer and closer to giving up on macOS as my operating system of choice. It’s been great, but things like this get under my skin a little. Now granted, this is low-impact for me currently - I don’t have remote login enabled on either of my laptops because if I want to access stuff on one of them I have physical access, and if I’m not near my personal laptop I’m probably at work and won’t need it or otherwise occupied and won’t need it.

      But if I had a desktop Mac? I could see allowing remote login. And I’d hate having to go through this every point release. It’s odd that they wrote the installer to just overwrite (what seems like) every file in the system folders when they could just overwrite the non-config files. But I suppose a blanket overwrite is easier for them to implement.

      1. 1

        I’m not convinced that allowing password logins is really that bad anyway. Any machine I put on the Internet would have something like blacklistd, fail2ban or sshguard. The trouble with keys is they’re only as secure as the system you store them on. If I left an ssh key at work to provide access to my home system, a colleague would be able to brute force the passphrase as fast as his machine could calculate them. Hammering and ssh daemon is going to be a lot slower than that and may not go unnoticed. In the blog authors case, this is presumably a laptop so they’d be actively using it while the attack takes place.

        1. 10

          I’m not convinced that allowing password logins is really that bad anyway.

          Most mac laptops (like the author was mentioning) won’t have blacklistd, fail2ban or sshguard. And when they connect to a LAN, they will, in their default configuration, advertise the availability of their ssh service over multicast DNS as soon as they are on the network. This includes potentially hostile wifi hotspots. (Though responsibly operated ones don’t let clients see each other, you’d possibly be surprised by how often you can connect to other machines on the same WLAN.)

          And if a key is only as secure as the system you store them on, the password is only as secure as the system you type it into. You really shouldn’t log in at all from systems you don’t trust. But if you’re going to, store your ssh key on a hardware token so that the untrustworthy system can only attack you while the token is physically there :)

          1. 2

            This really only should affect intermediate to advanced mac users, as sshd is not activated by default.

          2. 3

            Most of my personal machines have a fairly weak password because they’re only supposed to protect from someone physically typing a password into my machine. My laptop isn’t running blacklistd, fail2ban or sshguard. I sometimes bring my laptop to things like coffee shops, universities, friends, work, airports (well I used to…), and other places where I connect it to a LAN with people outside of my immediate family. I would really like it if random people on the LAN couldn’t try to brute force my password remotely.

            1. 1

              protect from someone physically typing a password into my machine

              then you shouldn’t turn sshd on.

              1. 2

                Why not? If it’s configured to not accept password auth, as it should, it poses no extra risks regardless of my account’s password.

            2. 0

              If I left an ssh key at work to provide access to my home system

              My initial questions would be: why do that, and if you have a really good reason, why not do it using a hardware key you take away with you?

              1. 1

                Because it is often useful to be able to get to personal e-mail and my own files while at work. For as long as I’ve had always-on-Internet at home I’ve simply got used to doing that. Many things like config files and general notes can be git cloned over ssh so it is simply really convenient.

                I’m sure it’s still more secure than most people’s habit of having their work browser left logged in to their gmail, facebook and whatever accounts. I should probably think about the hardware key idea but there is always a danger of forgetting it.