xinput keyboard spying does not work on virtual keyboards such as xvkbd! So unless an attacker is streaming a video feed of your desktop and tracking your mouse clicks, it's not going to be obvious what your passwords are. Because I'm paranoid, I've set up a window manager keybinding for xvkbd. I figure it can't hurt to get used to it. Edit: This is actually bad advice. Please ignore it. Streaming a video feed of someone's desktop without them noticing is pretty trivial, and there's no guarantee that Linux malware wouldn't do that. Not sure why I was so sure this was a good idea when I posted it actually...
Can you advise how you have set it up ? I have been using xvkbd for quite a while withthe following options set:- #include "XVkbd-common" xvkbd.windowGeometry: 800x320 xvkbd.secure: true xvkbd.keypad: false I hope that at least I have some sort of protection
@Ocky, that's pretty much all there is to it in this case. However Hungry Man makes a good point. @Hungry Man - yes, if an attacker has captured a video stream of your desktop while you type your password, that will be a problem. Hmm. I was going to say that streaming from within e.g. a compromised browser or chat client might be nontrivial, but there's no reason an attacker couldn't just invoke MPlayer with an argument list to do the streaming, or something like that. Blech.
@Hungry Man, you mean the same network transparency stuff that allows X forwarding over SSH? blargh why do I not think of these things
With ufw you can do "deny ssh" instead of just "deny 22," wouldn't that block ssh tunneled over any arbitrary port or am I mistaken? Same goes for VNC and such
@krustytheclown2 No, that only blocks port 22, which is the default for SSH. Likewise all the other UFW settings by service name. They're just macros for the default ports.
Ok, but if you look at the report of all programs/ports connected, and someone was running ssh from a random port, wouldn't the program show as "ssh"? I imagine that a sufficiently advanced attacker could figure out a way to mask it as dhclient or something else innocuous but I'm not aware of this being documented anywhere and it would probably take a pretty sophisticated hacker
@krustytheclown2 only if the program binary was called "ssh". It might be named "firefox" or "bash" or " .." instead. Or (more likely) a backdoor might be a modified version of a normally innocuous program - the real SSH might be swapped for a fake one, that behaves exactly like it except for sending your private keys off to some IP in Russia. Trying to work around a system being compromised is a bad idea. Which is why I edited my post above to indicate that it's bad advice. My apologies if I gave anyone wrong ideas here.
Local security is something to strive for, naturally. But it's also much more difficult - attack surface is massive compared to remote attack surface.