Comment by wahern
7 years ago
Whoever made this decision probably didn't appreciate that some people actually run sshd on port 22. OTOH, their remote desktop protocol uses a port above 1024, so it's already been possible to sniff passwords if you can race the daemon to bind the port (e.g. if you can induce it to crash). But two wrongs don't make a right.
Wouldn't TLS take care of this anyway? Sure, you can exploit a race condition and bind to the port before the legitimate service does, but you wouldn't be able to get that service's private key.
That's why launchd takes control of ports required by these kind of system services before the regular userspace is initialized.
If someone is not running sshd, I guess launchd would not take control of the port? And then someone on the same box could run their own fake sshd on the port, right? Leading potentially to the ability to capture keystrokes from any remote users who might "authenticate" and log in (to a fake terminal session provided by the daemon) through the port. What am I missing? Is it the case that launchd takes control of the port even if sshd is not configured to be active?