Hacker News new | past | comments | ask | show | jobs | submit login

Good grief I hope you never do this. Do NOT use a port > 1023 for anything that should run as root. If you do, and your machine gets compromised, any unprivileged user could start an ssh daemon, you might think, oh, why is the key different, accept it, and they've keylogged your login attempt.



I don't disagree in principle. In practice: how did they manage to start their own daemon on a port sshd is already bound to?


Web exploit, get a web shell, crash your ssh daemon somehow, start my own. Since it is running on a non-privileged port, easy enough to run my own ssh daemon there.

Crashing the ssh daemon isn't always easy, but, making the job easier for an attacker because 'obscurity' is considered a good protection scheme in this case opens up other potential vulnerabilities.


Linux' OOM killer, just to give one possible example.


This is only an issue if you're using password authentication and do not drop traffic on ports on which you are not running services.

Just use Single Packet Authorization, people.


It really depends on the scenario. Are you using one server? Do you manage a bunch of servers here and there for various clients? Are you responsible for corporate servers? All of them have different acceptable approaches to security.

On my on personal servers? Single-packet or port knocking or whatever, it's fun to play around - that's how you learn. At the enterprise? The internet can't ssh to anything - you need VPN access, and not just any but the correct VPN access, and the right credentials on audited machines. There's nothing for outsiders to knock on (except maybe the VPN - but that has auto-lockout and password rotation tied into the enterprise auth system)

If someone wanted to do port knocking or similar for enterprise stuff I think that'd be a staunch "Umm, no"


Thanks for this - this is good advice. Using a port over 1023 doesn't make sense and isn't necessary - the idea is to just change the port from the normal 22. Thanks!




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

Search: