This is most likely to an errant "xmodmap" somewhere in the shell init scripts on the Linux box. If you can run "xev" on the Mac you should be able to see which keycode the "e" key is generating. If you then look through the shell init scripts on the Linux side, you'll likely find that this keycode is being remapped to the backspace.
To make matters worse, this remapped key doesn't just apply to the X clients invoked via that particular ssh session, it will affect all X clients running on your Mac.
What I would suggest is modifying your init scripts on the Linux side so that they never invoke xmodmap for remote connections. The syntax depends on the shell you use, but it will be something similar to this (shown for tcsh):
if (! ${?REMOTEHOST} && ${?DISPLAY} ) then
# Make sure backspace is correctly mapped
xmodmap -e "keycode 22 = BackSpace"
endif
In fact, I'll wager you have an xmodmap line almost exactly like that. I note that on my FreeBSD machine keycode 22 is what my backspace key generates, but on my Mac keycode 22 is what my "e" key generates.
Yep, I've been down this road before on other operating systems. I actually thought my keyboard had gotten fried because the "t" key stopped working altogether. Turns out it was an errant xmodmap on a remote machine. 😟
Brent