Even better, port knocking on non-standard port.
As part of a comprehensive security plan I have no problem with it. I dont deploy any linux servers with ssh listening on 22 nor without fail2ban. Unfortunately, because of the vendors we use things like mandatory VPN or ssh keys only aren't in the cards.
Obviously things like passwords are security through obscurity, but the algorithm to hash the passwords should be well known.
Not exposing ssh means you will forget/not care you are running an old version and eventually this will bite you
Then port change, SSH hardening in general (key + pass, google pam auth module, etc), then fail2ban, denyhosts, sshguard, tallow, etc.
And all that doesn't matter if you don't see any alerts. Need a hids (I like OSSEC) and a good logging system for syslog etc alerts.
Number one issue I see with servers (besides badly secured in the first place), is a bunch of logs no one ever actually looked at.
That leaves port change, which is better than nothing. But even better than that is proper firewalling with whitelisted IPs.
If password authentication is a must then hopefully you can still go for 2FA (there's a few two factor authentication plugins for PAM). But if you do that then make sure you also stick fail2ban in there as well.
I think nobody argues that it adds security. The problem is that:
1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.
2. The security it adds is itself bad (sent in cleartext, easily brute-forced)
3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).
And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional.
That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program.
But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers.
I'm also not really a fan of leaving things with a shell connection on the net, again part of configuration. If you can root the ssh server, you could likely root a vpn box.
Also, I guess, I'm sorry, you're not allowed to ask questions on HN anymore. Thanks for the drive by down vote.
If you want to distinguish services, you should be giving them separate names/addresses. This is what the second half of an IPv6 address (the "interface" part) is for.
File sizes aren't an issue because auth logs take up such a negligible amount of space compared to the storage capacities we have at our disposal these days. But if your box is really that low capacity then stream your logs to a logging server (or push them to remote storage when you do your log rotate). Realistically you should be shipping your log files anyway.
Performance isn't really an issue either as larger auth logs isn't going to make sshd perform any better or worse.
There isn't really even a strong argument for the human readability impact as those logs should generally be parsed by robots instead of humans. Be it alerting systems like Nagios, reporting tools like Splunk, or firewall management services like fail2ban; in all cases you wouldn't typically be reading the auth logs in vi unless something has gone very wrong.
So I say just keep sshd listening on 22 and instead ensure your system is properly hardened (IP whitelists, SSH keys, etc) with automated processes in place that monitor the logs so you don't have to. Or better yet, don't expose SSH at all.
The down vote itself doesn't really bother me so much as the inability for misinformation to be corrected - be that my own error or whoever (which is why I always make a point of replying to people rather than down voting).