sudo non-user/non-root password
 

Stumped on this one. I'm trying to set up limited sudo authority on a desktop with some sensitive user data, and as an extra precaution I wanted to configure sudo to use a password other than the user's or the root's. I'm not sure how to do this. From the manual, we have a few options, such as "runaspw" or "targetpw", but none seem quite what I'm looking for.

For instance, "runaspw" could be used if I created a user for nothing other than sudo(ing) purposes, but it requires you set "runas_default", which means that said user would have to have authority to execute said commands in the first place. This is workable, but seems like a lot of extra configuration for each specific command that I want to run, as well as creating some issues with simply commands such as "shutdown" or "reboot". Also, "targetpw" can be used in conjunction with a sudo(ing)-only user if I set an alias, but, again, this isn't quite what I am looking for.

Ultimately, what I am really concerned about in this situation are keystroke loggers, so I would prefer to avoid repeated entering the user or root password when performing administrative tasks. Also, I would prefer not having to create a sudo(ing)-only user as mentioned above to prevent a comprimised password resulting in an attacker being able to log into my system.

Any ideas?

Most of what you say is beyond me, but you can make a user account that cannot login by setting their login shell appropriately. Some distros provide /sbin/nologin (like RHEL) which spits out a message saying login isn't allowed. Others tend to use /bin/false.
Usually that's used for things like samba-only users, but it might work for what you want to do.

Bear in mind you will need to make additional configuration to prevent them gaining (non-shell) access by ssh, as is discussed here: http://www.semicomplete.com/articles/ssh-security/

That was something I was considering, and might be the best solution. But as you said, there is the ssh issue. And there are god-knows what other exploits I'm not even aware of. But thank you for the response, this might be what I end up implementing if there are no better options.

Nevermind, the "targetpw" with sudo -u idea won't work. I don't know what I was thinking, but the -u option means run as user, which puts be back in the same place of setting some complex user permissions.

No other ideas on this one? Along with some restrictions on what commmands can be used, this seems like a simple way to greatly increase the security of sudo.

Maybe I should Mr. Miller and see if he would consider adding this feature.