Not at all. You only apply the "patch" when debugging symbols are off and optimisation is on, which would cover nearly any production build. Even if you left in debugging symbols, you would still have a hard time discovering it with a debugger since optimisation is supposed do change the output.
You would also make it trigger under very special circumstances and as others have pointed out, the error you introduce could be a subtle change of behaviour of the random number generator.
If you did that, the backdoor would disappear over the course of time whenever someone released a production compiler that was compiled with a debugging-symbol version of the same compiler. (This is a lot more likely than it seems; the people who actually develop compilers, and thus compile them, are likely to have debugging symbols on for their compilers as a matter of course, because they frequently make changes that break them.)
I remember to set a quick LC_ALL=C when I'm doing anything that might have to parse the output of a shell command (typically just on that command, rather than exported). Including the space you need to separate it from the command, it's what, nine characters? (And as a bonus, it forces things like the decimal point convention to known values too.)
(By the way, "C" is a better setting than any specific language, including English; its entire purpose is to be as portable as possible across computers. I've actually also come across programs that give more 'friendly' output on, say, "en_US.UTF-8" than they do on "C"; it's the difference between knowing that your output will be read by a human, or by a computer.)
The private key is normally protected by a password, without which it won't/can't work. The password doesn't need to be sent anywhere in order to work correctly.
SSH keys are actually one of the easiest ways to get two-factor authentication ("something you have" = the encrypted private key, "something you know" = the password to decrypt it.
A bunch of Pokémon fansites were hacked recently (here's one reasonably detailed report from one of the sites). Although as far as I know no plaintext passwords were stored on any of the servers, there were a bunch of password hash databases taken; and because Pokémon is a Nintendo property, Nintendo's website would be an obvious place to try any username/password pairs that were weak enough to be reversed from the databases (and some plaintext passwords would be available as a result of compromised login forms).
Many of the hacked sites (that I know about, at least) were reasonably small, with user counts measured in thousands; as such, 24 thousand total seems to be a reasonable estimate for the number of accounts that might have been affected.
"Don't drop acid, take it pass-fail!" -- Bryan Michael Wendt