Launchd context seems problematic after this init script runs

[NorseGaud]

I'm opening this on behalf of the Anka development team. It seems as if something this script is doing is preventing us from properly running Virtualization inside of the instances as the ec2-user. A lot of what will be below is paraphrased or copy and pasted. If it's unclear, please ask and I will get clarification.

---

Here is script being executed every reboot: /usr/local/aws/ec2-macos-init/init.toml The most suspicious part in the script is "ssh tuning": dscl /Local/Default delete /Groups/com.apple.access_ssh Probably macOS uses this group not only to control "allowed" ssh users but also for some other security questions. In any case, ssh session (StandardIO) context is completely messed on mac1.metal instances for now.

To reproduce the issue with the launchd context the simple test could be used:

launchctl submit -l test.job -- /bin/sleep 30

It fails for ec2-user in ssh session and succeeds for root and gui sessions.

[okudajun]

The failure of launchctl submit seems because of not /Groups/com.apple.access_ssh change but UsePAM no in /etc/ssh/sshd_config which is also modified from UsePAM yes and maintained by ec2-macos-init too.

Could you try to

• set secureSSHDConfig = false in /usr/local/aws/ec2-macos-init/init.toml,
• set UsePAM to yes in /etc/ssh/sshd_config, then
• reboot,

and confirm if your original workflow succeeds?

Please be careful that both PasswordAuthentication and ChallengeResponseAuthentication in /etc/ssh/sshd_config are no to prevent sshd from accepting password authentication.