"Dan Mahoney, System Admin" <[EMAIL PROTECTED]> writes: > The question comes up: "if I can get at your uid, why do I need your > screen?"
In order to observe the output when I run "gpg -d" on an encrypted, confidential file. Simply having my login password would not grant access to GPG encrypted files. In order to observe the output of commands run on a remote host via ssh. Simply having my login password would not grant access to the remote host. If I leave ssh running inside the screen session, to actively modify the remote host (e.g. installing your own public identity in the remote authorized_keys file). Similarly for other systems that require secondary passwords, such as a remote IMAP server or a remote web application. > Sadly, even though I am root on the systems involved -- the tweak we > really need here is extending screen's builtin lock to support the > password stored in .screenrc Clearly I don't know what you're talking about, because what I *thought* you were talking about works as you ask for. Namely, I run :password interactively to generate a hashed password in the default register. I use C-a ] to paste it into .screenrc, as in password ASDFASDFASDF Later, in either the current or a new screen session, I run :lockscreen. It blanks the screen, changing it to Screen used by Trent W. Buck <twb> Password: Screen password: The first prompt is for my login password. The second prompt is for my screen password. > -- otherwise it's a whole new pam > facility -- and PS, incidentally, pam doesn't have an easy way to say > "use the password in this file." echo password ASDFASDFASDF >~/.screenrc.secret echo source ~/.screerc.secret >>~/.screenrc _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users