SSH_ASKPASS behavior change proposal

[Lance E Sloan]

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/