Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article only briefly mentions port >= 1024 for non-root, but it's probably important to note that it is desirable to have the default port be < 1024. That way, you can be sure you are connecting to an sshd operated by the remote system's root user (and not, say, a random student's unix user account running a spoof sshd).

Obviously this matters more for multi-user systems, but even today it's nice to know that the sshd listen port on the remote end can't be hijacked by a random wordpress exploit kit (unless that kit also privesc's to root)



The port number shouldn't be used to give you information regarding a host's reputation. You should use fingerprints on initial connection and rely on the host keys for subsequent ones.


I thought you had to explicitly tell ssh to connect on a different port than 22 with the -p option which would prevent you from connecting to a spoof sshd.

I've only used it recently to get around McDonald's (apparent) throttling on port 22, moved sshd over to 443 and can saturate the wifi.


Bubkes. A middlebox can transparently rewrite incoming packets' port numbers from 22 to 2200, and backwards.


Absolutely.

But in a classic UNIX network, middleboxes aren't a part of the threat model.

Unprivileged UNIX user accounts binding on TCP ports were and are. So, ports below 1024 were reserved for the root account and that was a decent protection at the time against enterprising users trying to race system daemons in binding listening sockets.

See for example https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....

And even today, it still protects against an exploit kit running as "www-data" or "nobody" springboarded from a wordpress exploit.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: