That address is an APNIC /8 (Asia) and depending on who's whois you trust its in Japan. One of MANY defense in depth steps is to toss out all sshd traffic other than certain trusted ip ranges. Unless your server is in Japan or you live in Japan there is little reason for anyone in Japan to ever be able to ssh into your machine.
Not entirely unreasonable to only run SSH (and other things) on a VPN connection. Again, defense in depth this is hardly the only step required.
Another amusement is port knocking. No need to get all crazy and send 512 bit keys before a script temporarily opens the ssh port, remarkably little is usually enough. TCP SYN packets to SSH are only permitted for 5 minutes after a simple telnet to open TCP port ABC or whatever.
I totally agree with putting SSH on a whitelist, such a great strategy.
The VPN is a little trickier, because you're basically just exchanging your exposure from SSHD to VPN (unless you're referring to something else). I'm not sure whether that's a good idea or a bad idea, but it's something to be aware of.
I've found that white-listing SSHD (and silently dropping instead of rejecting other traffic), along with Key-Login + disabled root login has been the best I can do for preventing anything.
SSH over VPN does a couple things. First it reduces your attack surface. Surely you must have a VPN, and you must have remote SSH access, but now the internet can only poke (directly) at the VPN and no longer (directly) at the SSHd.
Assuming someone centralizes and audits and updates authorized employee lists on the VPN server, there's no way J.Random.Admin who just got fired could have some ssh keys on some random server; well, he could, but IT chopped his VPN access as he walked out the door, so they're inaccessible.
Its very difficult to set something like openvpn up such that all someone needs to know is "password123" and he's in. Fairly easy with ssh. Design to tolerate human error. You can't accidentally enable password auth instead of key auth if the system doesn't even support password auth.
Its nice to be able to document to the security guys that nothing, and I mean nothing, flows in or out of company property that doesn't go over the VPN.
Finally, although this is kinda lame, setting up SSH over VPN encourages people to do everything over VPN, hey see it wasn't so hard to put SSHd on the VPN only, so why don't you remove internet wide accessibility (insert exclamation points here) for mysql and your application admin console thingy and your VNC server and ...
If you want to mess with peoples minds, put ssh on a TOR hidden service. This freaks some people out. A bot port scanning in China doesn't know what to think of your box only being accessible via a TOR hidden service. Its not hard to set up. Have fun with connect-proxy. Although this smells of security thru obscurity, its really just one of hopefully many layers of defense.
Not entirely unreasonable to only run SSH (and other things) on a VPN connection. Again, defense in depth this is hardly the only step required.
Another amusement is port knocking. No need to get all crazy and send 512 bit keys before a script temporarily opens the ssh port, remarkably little is usually enough. TCP SYN packets to SSH are only permitted for 5 minutes after a simple telnet to open TCP port ABC or whatever.