SSH_ASKPASS behavior change proposal
Iain Morgan
imorgan at nas.nasa.gov
Sat Jan 20 04:08:49 EST 2007
You could address the CVS/SVN issue using session multiplexing. See the
entries for ControlMaster and ControlPath in the ssh(1) man page.
Sometime ago, Lance E Sloan wrote:
> Hello, OpenSSH Developers!
>
> I'm not a member of the OpenSSH development team or a member of this
> mailing list. I have a small change to propose for OpenSSH and since
> the mailing list page at openssh.com indicated the general discussion
> list is for support, I thought this list would be a better place to
> discuss this. Please forgive me if I've committed a faux pas.
>
> I propose that the ssh command-line client be changed so that it will
> use whatever program is specified in the SSH_ASKPASS environment
> variable regardless of whether ssh has a terminal associated with it or
> not. In order for this to work, SSH_ASKPASS would need to contain the
> full path to a program that prompts for a password, DISPLAY would also
> need to be set, and some additional environment variable would need to
> be set to instruct ssh to ignore the no-tty requirement.
>
> My reason for proposing this is because the system administrators at my
> organization do not allow us to keep public keys for ssh
> authentication. They have put a "PubkeyAuthentication no" directive in
> the sshd_config file on our servers. They have two reasons for doing
> this. First, I believe they think this is more secure. Second, and
> more importantly, the interactive password authentication on these
> servers also gets Kerberos tickets and AFS tokens for the user as they
> log in. This latter part could probably be accomplished by the user
> keeping their Kerberos authentication information in an encrypted file,
> but it would be very hard to guarantee the security of that file.
>
> This inability to use public key authentication with ssh makes it very
> difficult, sometimes even impossible, to use CVS or Subversion clients
> with repositories on those servers. Some operations with these clients
> may require several individual commands to the repository. Some CVS or
> SVN clients might then prompt the user for their password with each
> command while some clients just fail. Using a stock ssh client from
> OpenSSH with the path to a password prompting and caching program in
> the SSH_ASKPASS environment variable will solve the problem for most
> CVS or SVN GUI clients, since they usually do not have a terminal
> associated with them.
>
> Using a command-line CVS or SVN client with repositories on those
> servers is still a problem, though. The command-line client obviously
> has a terminal associated with it, so ssh would not normally invoke the
> password prompting program indicated by SSH_ASKPASS. If the user is to
> run a script with many CVS or SVN commands in it, they will be prompted
> for their password every time. Besides running scripts, there are
> plenty or reasons why one would want to use a command-line CVS or SVN
> client, especially if the available GUI clients are broken or quirky.
>
> As a test of my proposal, I changed the readpass.c file in my copy of
> the source to look for an environment variable named
> "SSH_ASKPASS_IGNORETTY". If that environment variable is set, the
> use_askpass variable is set in the code. With that variable set
> (SSH_ASKPASS and DISPLAY are set appropriately, too), when I run a
> command-line CVS or SVN client against a repository through ssh on a
> server that requires passwords, the program I specified is started and
> supplies the password to ssh.
>
> Currently, the program I specify with SSH_ASKPASS prompts me for my
> password and can optionally cache the password in my account to avoid
> prompts in the future. It is a GUI program written just for this
> purpose that I found on the Internet. I am working on a replacement
> for this program that would prompt for and optionally cache passwords,
> but also give the user the choice of storing it (as the current program
> does) or to just cache the password in memory for as long as the user
> is logged in.
>
> I hope that my proposal is reasonable. I welcome your thoughts,
> discussion, and critique. (Constructive criticism only, please.)
>
> Thank you for your time!
>
> --
> Lance E Sloan, Application Developer
> Evil is my middle name. Some people think it's Eugene, though.
> U-M ITCS ITCom Information Systems
> http://www.itcom.itcs.umich.edu/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
--
Iain Morgan
More information about the openssh-unix-dev
mailing list