> do you define a user job that runs in the background even when the user's not logged in?
Well, you can't. Only administrators get to define things that run when the user isn't logged in. That's an intentional decision.
> How do you define a user job that runs if the user logged in via SSH
Offhand, I don't think you can do that either, though I haven't researched this particular angle. And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.
> And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.
You might want to find out about systemd, then, which does exactly this. (-:
A PAM hook indirectly causes a per-user systemd instance to be created at login and terminated at logout, which triggers all of the per-user daemons that the account has.
If one has a user that is used for lots of little SSH sessions, hundreds of thousands of times a day, the overhead of starting up and tearing down the per-user systemd for each one, not least in terms of the log noise, becomes a serious consideration, and one has to learn the systemd mechanisms for making the user a "lingering" one.
For an OS that is frequently used headless, starting up per-user daemons on SSH makes some amount of sense. macOS is designed to be primarily GUI-driven, rather than primarily used headless, so it makes more sense for macOS to avoid the issue that you describe by not supporting launching per-user daemons on SSH.
I was assuming administrative control of course. How, as the administrator, do you define such user jobs? It's not a permissions issue, its a launchd job configuration issue.
Well, you can't. Only administrators get to define things that run when the user isn't logged in. That's an intentional decision.
> How do you define a user job that runs if the user logged in via SSH
Offhand, I don't think you can do that either, though I haven't researched this particular angle. And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.