If you believe in stuff like this, then do it right: require the attacker to know a secret algorithm (like "AES with 3 extra rounds") to talk to you.
1) the guy would also need the HMAC key, or 2) the zero-day is in the code that looks at the HMAC signature.
It's not that I only count on this for security, but it's a matter of reducing the attack surface. Likewise, I don't have passwordless guest accounts on all my servers, since that would make the attack surface even greater.
1. break into your machine?
2. break into some machine?
if (1) then i certainly agree that none of this really matters (i apologise if that wasn't clear from my previous comment).
on the other hand, if his objective is (2), and not everyone is using some of this obfuscation, then this separates you from the crowd for a little while (but my model is that as time goes on, you are inevitably exploited).
i realise after your company was exploited it might make you feel like (1) is always the case but for many (2) is the salient threat.
People with SSH zero-day are not, by and large, looking to burn those vulnerabilities by spraying them into every busybody's honey pot logs.
Actually the people looking to break into your machine are targeting windows clientsides and weeks-to-months-old web vulnerabilities.
There's a cost involved in developing 0day, droppers, remote access trojans, maintaining breach and exfil teams etc. If these guys can get into the developer laptops with an email, a wink and a PDF then why waste the 0day? If you're putting all your effort into a custom SSH daemon without expending equivalent effort on your connection sources (especially when connecting to the Internet) then you're doing it wrong.