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