To my knowledge the word sniffing does not only belong to observing network traffic. See i.e. http://www.seifried.org/security/articles/20020126-keyboard-sniffing.html or http://www.wired.com/news/privacy/0,1848,49455,00.html.
True.. I guess in the world of corporate America that I work in, on our networks and under ITIL we use 'sniffing' only to pertain to packets.
I would call keyboard 'sniffing' to be logging, interception, etc.. but yes, in a way.. you're sticking your nose out there and seeing what goes by... That was completely my mistake.
Lastly, you might be able to record it via injected modules using LD_PRELOAD.. But i've never researched this method in depth.. You can easily use LD_PRELOAD though to bypass restricted shells. (Nothing to do with this).
Well, you are right in may aspects. Maybe I was too short with my comment. I did not say and didn't want to say that logging in as normal user and then su to root is insecure at all. I just wanted to say that it weakens the root login, against the possibility to use public key authentication with SSH login. Not more, not less. I am no hacker nor cracker, so I have no proof of concept for using the possibility to "listen" to the input a user makes when su'ing. Again: it would be a local hack. I am not speaking about decrypting the SSH connection, either established by password auth nor by pubkey auth. The "weak" point is the local system, given the attacker has local unprivileged user permissions.
I know you weren't talking about decrypting ssh, etc. While I'm not a big fan of allowing any remote root access.. I do see where you are coming from.. If someone compromised your home machine/certificate/passphrase, they would have instant root access to your sshd box. However, if you were ssh'ing and su'ing, and they had compromised the box doing the ssh'ing, they'd still compromise root if you ever su'd.
Remote root access via keys and using 2 factor authentication (tokens, etc) wouldn't be too bad at all.. but for the purposes of auditing, its usually not plausible. There needs to be an audit trail. I think the way to go would be using su, and still having 2 factor.. At the same time, I use gr-security on my kernels which doesn't allow a user to put anything in their own path (gets around their account being compromised, and someone trojan'ing su).
It's never completely fool proof.. and using RSA tokens certainly isn't affordable or easy for a home user. Things like S/Key are, but they're a pain to carry around a list of passwords.. Biometrics aren't really plausible (and are a bad thing in general in my opinion.. If someone ever compromises your thumb print.. Oops, you're screwed forever)
Both ways have their issues.. Personally, I'm not a fan of passwords at all.. But if you use public key, then you run into the problem of your users not setting passphrases on their keys at all.. Which you can't really control.. and then their windows/linux box getting compromised, and the attacker doesn't even have to go through the hassle of sniffing their passphrases.. they just walk onto your system.. as a normal user. Then they can attempt to escalate privs from there.
So anyway.. I see where you're coming from, and I see the extra risk of a user account being compromised and then someone attempting to escalate from there if they are a user that has 'su' ability. But this is also the reason that root users should be extremely limited.. sudo is great for doing this, as long as you know exactly what you're doing.. So many applications have shell escapes.. like giving sudo vi, is just like giving sudo bash.. sudo cat, gives shadow file (also gives raw access to /dev devices.. sudo cat /dev/hda|strings)
However you can restrict sudo down pretty well, require absolute paths, etc.
anyway.. I've rambled enough.
