It doesn't. If anything change the line SSH emits and how it identifies itself. You want the automated tools to send the wrong exploits. If you can make your OpenBSD machine look like a Windows server running a commercial SSH server you're going to deflect a lot of attacks / attract the wrong kind of attacks.
The proper way to do something like this is generally three fold:
1) Trusted host (OpenBSD?) that runs only SSHD, and only allows users to run ssh from the shell. Log the fuck out of this server, and likely port mirror and record raw packet logs. Since no one should be talking to this machine except for SSH simply drop everything from those IPs when you recieve something other than SSH.
2) Ensure all other servers only accept SSH connections from the trusted host.
3) Restrict unconditional access to the trusted host to a list of trusted IPs, turn off all unused SSH options, you probably don't need that many if all it is doing is proxying connections to other hosts. Now that you have a list of trusted IPs you can be very aggressive in firewalling malicious connections from non-trusted IPs. (It's nice to have some way to getting back into your infrastructure when you're on vacation, etc)
Generally the best thing for security is a default deny rule. Chances are your database server doesn't really need to connect to the internet. Chances are your webservers only require inbound connections on ports 80 and 443, and only make outbound connections to your database & log server.
Fuckery with port numbers is generally a waste of time. The best thing for an attacker to do is extensive slow scanning in advance, then when an exploit comes out it's a quick lookup in a DB for likely vulnerable systems.