"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
[email protected]
http://lists.gnu.org/mailman/listinfo/screen-users
