Opened 11 days ago
Last modified 10 days ago
#72345 assigned defect
openssh: Daemon does not produce logs when running
Reported by: | joshqou (Josh Qou) | Owned by: | artkiver (グレェ) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.5 |
Keywords: | monterey | Cc: | |
Port: | openssh |
Description
OpenSSH doesn't seem to talk to Apple's logging system.
Running even with AuthLevel VERBOSE doesn't give anything in Console or through the log command. The only way I'm able to get log output is by specifying -E in OpenSSH.wrapper
The only output I get in the system log is from apple libraries running in sshd-session. Not anything that's actually from sshd like attempted logins.
Enabling the builtin sshd in Sharing seems to result in the same behaviour so this may be an upstream issue?
Am I mistaken in expecting sshd to log to the system journal by default or do I need to pass it an option to do so?
Change History (2)
comment:1 Changed 10 days ago by jmroot (Joshua Root)
Owner: | set to artkiver |
---|---|
Status: | new → assigned |
comment:2 Changed 10 days ago by artkiver (グレェ)
Note: See
TracTickets for help on using
tickets.
Thanks for the observation.
Personally, I basically only have Apple laptops these days and so I don't really make much use of sshd, so I don't have meaningful perspective to share.
Anecdotally, I haven't worked anywhere that had Apple XServe systems in an very long time and Apple also discontinued their OS X/Server software line last updated that in their App Store in 2022.
Which is to say: my experience is that without assiduous use of /usr/bin/caffeinate to keep macOS from sleeping with abandon, it is remarkably ill suited to anything daemon/server related and I treat it with such constraints in mind. (I tend to prefer BSDs for 24x7 server/daemon suited systems) I get the impression Apple treats macOS that way too based on the writing on they have left on the wall as it were.
"Enabling the builtin sshd in Sharing seems to result in the same behaviour so this may be an upstream issue?"
Without having looked into it further, that seems as if it is probably indicative that this isn't specific to MacPorts' OpenSSH?
Not to suggest that MacPorts can't have macOS specific patches to change functionality from upstream behavior, but a much more pressing set of patches that need review and improvement and help from others to me right now are documented in this Trac issue which I opened recently: https://trac.macports.org/ticket/72317
Since in that instance, those two patches breaking with 10.0p1/2 impacts existing MacPorts' functionality. I've contemplated just submitting a Pull Request for 10.0p1/2 as it stands without those patches, but was kind of hoping that other MacPorts' contributors might be able to assist where I have come up blank?
TL;DR this issue can probably be addressed, somehow, but it's not going to be a very high priority for me at the moment. Patches welcome!