And for the one-millionth time... this isn't a "security risk".
What IS a security risk is not running the latest version of SSH. Anything else is just skirting the issue (i.e. not being up-to-date but "pretending" that you are... it won't fool anybody but yourself).
Most attackers, when faced with a particular server they wish to attack, will of course see the version number. However, absence of a version number, one that isn't valid or one that isn't the very latest is an indication that the server administrator probably ISN'T running the latest version and therefore it's worth trying EVERYTHING that works for ANY version.
And additionally, most tools of the kind that would attack ignore things like reported version strings and either a) blindly try everything on every server they find or b) use heuristics to "guess" what the real version is or whether it's vulnerable (you can't really do this for SSH because nobody has really bothered to make a comprehensive tool because of the "you can't disable the version string" code - which means that any SSH attacks will blindly attack anyway).
If anything, this draws attention to you, rather than puts people off. Seriously... which of these reports on your "ultra-cracking-tool" would you pay more attention to:
I know which four I would pay more attention to. And when we're talking about SSH, which potentially allows root access instead of just "nobody:nogroup", it suddenly becomes a lot more important to keep up-to-date.
And then you have the problem that "faking" the version string (which is of course technically feasible) will pretty much break most SSH clients (PuTTY for one), because it relies on knowing the particular quirks of certain servers/versions for SSH (e.g. workarounds for bugs in old versions of OpenSSH).
Don't play at security, and especially not SSH - keep it updated or don't use it at all.