Created attachment 12 [details]
Adds SSH_ALWAYS_ASKPASS env var and removes check for $DISPLAY

hmmm, alternately you can fake it by setting "DISPLAY=foo"

>hmmm, alternately you can fake it by setting "DISPLAY=foo"

But this is an ugly workaround. Then *other* applications might think that there
actually is a working Xserver available. 

Face it: The need for transmitting a password to SSH in a secure way has
*nothing* to do with X11 or terminal ttys, at all. Most applications have some
good mechanism for doing this (vncviewer, rdesktop, smbclient, etc); it's just
crazy that OpenSSH doesn't. 

Personally, I prefer a new option instead of SSH_ALWAYS_ASKPASS, but that is no
big issue. 

I also think that the host key confirmation should not use SSH_ASKPASS, but
another variable (for example, SSH_KEY_CONFIRM). The current GUI which requires
the user to type "yes" is very un-intuitive. People just don't understand it.
The GUI should have a "Yes/No" button dialog instead, just like Putty have. 

This bug also affects use of openssh under the Opie palmtop environment, and the
current hackish workaround is to set the DISPLAY variable -- which _can_ have
the effect of confusing some programs into thinking they're running in an X
environment instead of under Opie, and doing the wrong thing.

The presence or absence of a $DISPLAY should be entirely irrelevant to ssh when
deciding whether to use $SSH_ASKPASS or not.

There's certainly a case for contining the 'if a tty is available, use it'
behaviour, but it should certainly be _possible_ to override that in some way
other than actually detaching from the tty to prevent ssh from trying to use it.

i don't think DISPLAY is confusing if you just set it for ssh.
other programs don't care.

as to typing "YES", this is intentional, since users should _think_
not click.

Even if the DISPLAY requirement is not removed, we still need some method to
trigger askpass usage if the tty is a terminal. 

Regarding the host key confirmation GUI: Having a non-intuitive GUI does not
make people think more. Instead, they becomes occupied with the task of getting
rid of the dialog. 

Created attachment 722 [details]
Patch to make use of SSH_ASKPASS more configurable

$SSH_USE_ASKPASS may be set to "never", "always" or "preferred", to choose
whether passwords should be always read from tty, always via SSH_ASKPASS or via
SSH_ASKPASS, if available ($DISPLAY) is set.

Comment on attachment 722 [details]
Patch to make use of SSH_ASKPASS more configurable

Isn't USE_SSH_ASKPASS=prefer redundant? That would just be the default if it
wasn't specified, right?

The problem with "Command Line Password Support" is discussed again in the mail list and in this thread "http://marc.info/?l=openssh-unix-dev&m=122002002422109&w=2" is reported that password authentication never work with proposed workaround : to set DISPLAY and SSK_ASSPASS environment variables. Also this impact batch sftp transfers too.

If public key authentication is allowed the known work-around is to add key to agent and to use it. This is because ssh-add call read_passphrase(...) with RP_ALLOW_STDIN flag set and if stdin is not tty SSK_ASSPASS program is called.

For the password authentication and other since read_passphrase(...) is called without any flags set the work-around is to disable temporary read or write access to /dev/tty. In this case function will try to use SSK_ASSPASS program.

Instead to use application command line arguments or environment variables as flag what about variable SSK_ASSPASS_ALWAYS with same meaning as SSK_ASSPASS. May I propose following modification to funnction read_passphrase :
...
rppflags = (flags & RP_ECHO) ? RPP_ECHO_ON : RPP_ECHO_OFF;
if (askpass = getenv("SSK_ASSPASS_ALWAYS")) /*new line*/
   use_askpass = 1;                         /*new line*/
else if (flags & RP_USE_ASKPASS)            /*modified line*/
...
if (use_askpass && (askpass || getenv("DISPLAY"))) {  /*modified line*/
    if (!askpass)                                     /*new line*/
    if (getenv(SSH_ASKPASS_ENV))
....
At moment I don't have time to prepare patch and to test. May be next week.

Date: Thu, 28 Aug 2008 15:08:18 -0400
From: Jim Knoble <jmknoble@pobox.com>
To: openssh-unix-dev@mindrot.org
Subject: Re: SSH Command Line Password Support
Message-ID: <20080828190818.GB13711@crawfish.ais.com>
Mail-Followup-To: openssh-unix-dev@mindrot.org
References: <876324.11513.qm@web30706.mail.mud.yahoo.com>
 <867ia2963m.fsf@ds4.des.no>
 <alpine.BSO.1.10.0808271359360.14747@fuyu.mindrot.org>
 <slrngbahdp.c3c.janfrode@lc4eb5760521341.ibm.com>
 <87y72itrl7.fsf@squeak.fifthhorseman.net>
 <20080827185507.GD233@greenie.muc.de>
 <87iqtmkusk.fsf@squeak.fifthhorseman.net>
 <alpine.BSO.1.10.0808280155290.3864@fuyu.mindrot.org>
 <20080828083820.GC2874@apb-laptoy.apb.alt.za>
In-Reply-To: <20080828083820.GC2874@apb-laptoy.apb.alt.za>

Circa 2008-08-28 04:38 dixit Alan Barrett:

: On Thu, 28 Aug 2008, Damien Miller wrote:
: > [old SSH_ASKPASS proposals:]
: > >  http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2
: > >  https://bugzilla.mindrot.org/show_bug.cgi?id=69
: > 
: > I think we should do something like this, but I remember having some
: > issues with the user-interface.
: 
: I don't like having new environment variables like
: WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or
: any other variations on this theme.  I'd prefer to see ssh simply use
: SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY
: or a tty.  If the user wants conditional behaviour, they can set
: SSH_ASKPASS to point to a script that does whatever tests they like when
: it is invoked, or they can use a script to conditionally set SSH_ASKPASS
: to different values before they invoke ssh.
: 
: Alternatively, you could put all the complex policy like "use
: SSH_ASKPASS if foo and not bar" into the configuration file, and let
: SSH_ASKPASS continue to be the only environment variable related to
: this issue.  The main thing is that I want no more than one environment
: variable for this.

Disclaimer:  I'm the creator of x11-ssh-askpass
<http://www.jmknoble.net/software/x11-ssh-askpass/>.

I believe the best way to handle this is with an ssh_config file option
(which can then also be used on the command line).  ssh-add(1) and
ssh-agent(1) also use SSH_ASKPASS and should use a command-line option,
since they don't read ssh_config files.

This allows for the greatest combination of flexibility and backward
compatibility.  For example:

    ssh -oUseSshAskpass=auto
    ssh -oUseSshAskpass=yes
    ssh -oUseSshAskpass=no

    "auto": the current method, and the default.
    
    "yes": ignore the presence or absence of a controlling terminal
    and a DISPLAY variable, and just use SSH_ASKPASS if it's set.
    
    "no": ignore SSH_ASKPASS; always prompt the terminal for a
    passphrase or confirmation (if no terminal, fail?).

    "ssh-agent"    => UseSshAskpass=auto
    "ssh-agent -p" => UseSshAskpass=yes
    "ssh-agent -P" => UseSshAskpass=no

    "ssh-add"      => UseSshAskpass=auto
    "ssh-add -p"   => UseSshAskpass=yes
    "ssh-add -P"   => UseSshAskpass=no

Folks who expect the current way of doing things don't have to change
anything.  Folks who want something different can use the command-line
or ssh_config options.  Folks who want something fancy can use
"UseSshAskpass=yes", create wrapper scripts for ssh-add(1) and
ssh-agent(1), and set SSH_ASKPASS to a script which determines what to
do, as Alan Barrett suggests.  

Comments?

Date: Fri, 29 Aug 2008 16:22:39 +0200
From: Alan Barrett <apb@cequrux.com>
To: openssh-unix-dev@mindrot.org
Subject: Re: SSH Command Line Password Support
Message-ID: <20080829142239.GA13113@apb-laptoy.apb.alt.za>
References: <876324.11513.qm@web30706.mail.mud.yahoo.com>
 <867ia2963m.fsf@ds4.des.no>
 <alpine.BSO.1.10.0808271359360.14747@fuyu.mindrot.org>
 <slrngbahdp.c3c.janfrode@lc4eb5760521341.ibm.com>
 <87y72itrl7.fsf@squeak.fifthhorseman.net>
 <20080827185507.GD233@greenie.muc.de>
 <87iqtmkusk.fsf@squeak.fifthhorseman.net>
 <alpine.BSO.1.10.0808280155290.3864@fuyu.mindrot.org>
 <20080828083820.GC2874@apb-laptoy.apb.alt.za>
 <20080828190818.GB13711@crawfish.ais.com>
In-Reply-To: <20080828190818.GB13711@crawfish.ais.com>

On Thu, 28 Aug 2008, Jim Knoble wrote:
> : > [old SSH_ASKPASS proposals:]
> : > >  http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2
> : > >  https://bugzilla.mindrot.org/show_bug.cgi?id=69
> 
> I believe the best way to handle this is with an ssh_config file option
> (which can then also be used on the command line).  ssh-add(1) and
> ssh-agent(1) also use SSH_ASKPASS and should use a command-line option,
> since they don't read ssh_config files.

Having to use command line options for ssh-add and ssh-agent may be
inconvenient in some environments.

It occurs to me that the policy on when to use SSH_ASKPASS
could also be embedded in the variable itself, like this:

  SSH_ASKPASS="/path/to/script"        # like today
  SSH_ASKPASS="always:/path/to/script" # use it regardless of DISPLAY or tty

--apb (Alan Barrett)

Date: Thu, 28 Aug 2008 15:24:22 -0500 (CDT)
From: Ben Lindstrom <mouring@eviladmin.org>
To: openssh-unix-dev@mindrot.org
Subject: Re: SSH Command Line Password Support
In-Reply-To: <20080828190818.GB13711@crawfish.ais.com>
Message-ID: <alpine.BSO.1.00.0808281458000.5006@miyako.eviladmin.org>
References: <876324.11513.qm@web30706.mail.mud.yahoo.com>
 <867ia2963m.fsf@ds4.des.no>
 <alpine.BSO.1.10.0808271359360.14747@fuyu.mindrot.org>
 <slrngbahdp.c3c.janfrode@lc4eb5760521341.ibm.com>
 <87y72itrl7.fsf@squeak.fifthhorseman.net>
 <20080827185507.GD233@greenie.muc.de>
 <87iqtmkusk.fsf@squeak.fifthhorseman.net>
 <alpine.BSO.1.10.0808280155290.3864@fuyu.mindrot.org>
 <20080828083820.GC2874@apb-laptoy.apb.alt.za>
 <20080828190818.GB13711@crawfish.ais.com>

On Thu, 28 Aug 2008, Jim Knoble wrote:

> Circa 2008-08-28 04:38 dixit Alan Barrett:
>
> : On Thu, 28 Aug 2008, Damien Miller wrote:
> : > [old SSH_ASKPASS proposals:]
> : > >  http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2
> : > >  https://bugzilla.mindrot.org/show_bug.cgi?id=69
> : >
> : > I think we should do something like this, but I remember having some
> : > issues with the user-interface.
> :
> : I don't like having new environment variables like
> : WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or
> : any other variations on this theme.  I'd prefer to see ssh simply use
> : SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY
> : or a tty.  If the user wants conditional behaviour, they can set
> : SSH_ASKPASS to point to a script that does whatever tests they like when
> : it is invoked, or they can use a script to conditionally set SSH_ASKPASS
> : to different values before they invoke ssh.
> :
> : Alternatively, you could put all the complex policy like "use
> : SSH_ASKPASS if foo and not bar" into the configuration file, and let
> : SSH_ASKPASS continue to be the only environment variable related to
> : this issue.  The main thing is that I want no more than one environment
> : variable for this.
>
> Disclaimer:  I'm the creator of x11-ssh-askpass
> <http://www.jmknoble.net/software/x11-ssh-askpass/>.
>
> I believe the best way to handle this is with an ssh_config file option
> (which can then also be used on the command line).  ssh-add(1) and
> ssh-agent(1) also use SSH_ASKPASS and should use a command-line option,
> since they don't read ssh_config files.
>
> This allows for the greatest combination of flexibility and backward
> compatibility.  For example:
>
>    ssh -oUseSshAskpass=auto
>    ssh -oUseSshAskpass=yes
>    ssh -oUseSshAskpass=no
>
>    "auto": the current method, and the default.
>
>    "yes": ignore the presence or absence of a controlling terminal
>    and a DISPLAY variable, and just use SSH_ASKPASS if it's set.
>
>    "no": ignore SSH_ASKPASS; always prompt the terminal for a
>    passphrase or confirmation (if no terminal, fail?).
>

To me the above makes no sense at a glance.  I'd rather see 
"UseSshAskpassWithoutX11 {Yes/No}" or something that clearly defines that 
when 
using SSH_ASKPASS what the behavior one is to expect from it.

Only advantage yours provides is if someone wants to disable it period 
regardless of DISPLAY= and SSH_ASKPASS= being set (which

Problem is I can't come up with something that makes good sense at a 
glance.  "AUTO" to me makes no sense.  Why would "AUTO" and "YES" (without 
reading a manpage) be different.

I guess I could see the syntax being "UseAskpass {X11,Yes,No}" .. I hate 
pinning stuff to X because that may not be the case for Windows or Mac. 
However, seeing our use of it all over the ssh_config it make it 
consistant.

Besides that the rest of the proposal is fine to me.


BTW.. Thinking through this.. Had we been discussing implementing this 
today a new feature I'd be arguing that it would be SSH_ASKPASS program's 
job to care if DISPLAY= was set, but legacy issue trump this choice these 
days.

- Ben

Alan Barrett's comment in #11 is a much more elegant solution than the one i proposed.  In case it's not obvious, there are 3 possible states:

(1) Current behavior (depends on whether DISPLAY is set and there is a controlling tty):

    SSH_ASKPASS="/path/to/file"

(2) Always use SSH_ASKPASS, ignoring whether DISPLAY is set and whether a controlling tty exists:

    SSH_ASKPASS="always:/path/to/file"

(3) Always prompt on the tty, unless there isn't one, in which case, fail if a passphrase or confirmation is required:

    SSH_ASKPASS="", or
    (SSH_ASKPASS is unset, i.e., not present in environment)

The third state is not explicit in Alan's comment.  States (1) and (3) are both current behavior, thus they are completely backward compatible with current implementations.  State (2) requires command-line options for ssh-add or ssh-agent.

Nice work, Alan.

Jim Knoble wrote:

--------------------
(2) Always use SSH_ASKPASS, ignoring whether DISPLAY is set and whether
a controlling tty exists:

    SSH_ASKPASS="always:/path/to/file"

[...] State (2) requires command-line options for ssh-add or ssh-agent.
--------------------

That should read, "requires NO command-line options for ssh-add or ssh-agent".

I vote for SSH_ASKPASS="always:/path/to/file". May be modification code has to be similar to that I propose in #9.

For the current code in a X-terminal "nohup ssh-add .."  (DISPLAY is set) is enough to get SSH_ASKPASS window.

May be Jim and Damien will update respective ssh-askpass GUI programs to use tty if DISPLAY is not set ?

Created attachment 1599 [details]
allow "always:" prefix in $SSH_ASKPASS

This patch adds support for certain prefixes in $SSH_ASKPASS:

 * "always:" always use the given program to ask for a passphrase,
   never use the tty/stdin

 * "never:" always use tty/stdin to ask for a passphrase, fail if the 
   caller requestes ssh-askpass via RP_USE_ASKPASS

 * "auto:" or no prefix: automatically determine whether to use 
   ssh-askpass, like before

The ssh-askpass program can be specified after the colon, or as the whole of $SSH_ASKPASS, if there is no prefix.  If the program specification is empty, the compiled in default is used via _PATH_SSH_ASKPASS_DEFAULT.  If $SSH_ASKPASS is unset this is equivalent to $SSH_ASKPASS set to the empty string.

Apart from the the prefixes, this differs in how it treats an empty $SSH_ASKPASS; previously it would blindly execute the empty string, now it will use the compiled in default for ssh-askpass.  This is what was always done for unset $SSH_ASKPASS.

Created attachment 3347 [details]
enable always: prefix in SSH_ASKPASS, updated patch for OpenSSH 8.0

Hello,

I also desire this feature. The reason is consistency. With 'AddKeysToAgent ask' in my ssh config, the following would happen when connecting to a host for the first time:

1. ssh to host
2. ssh asks for passphrase for private key *on the terminal*
3. ssh asks whether to add they key to the agent *via ssh-askpass* - and even fails if there's no askpass!

This is silly and inconsistent. Either use the terminal for both, or askpass for both.

So I decided to go the ssh-askpass route (using a small wrapper script to use pinentry, no need for another program when I already have pinentry on my system)

I have updated the patch from attachment 1599 [details] (comment 16) for OpenSSH 8.0. Find it attached. I did some short tests and it appears to work as intended. Maybe it's useful to someone, and I would be happy to see this patch upstreamed - this bug has been open since 2002 :)

Cheers!

Would also like to see progress on this. ASKPASS and DISPLAY entanglement is causing headaches on Windows where askpass is not present.

Am interested in the history behind read_passphrase forcing ASKPASS semantics even despite callers explicitly omitting the RP_USE_ASKPASS flag. That seems... aggressive.

OpenSSH 8.4 will include a $SSH_ASKPASS_REQUIRE variable that accepts force|prefer|never options.

Mass close of all bugs fixed in 8.4 release.

SSH_ASKPASS_REQUIRE works. Thanks for the implementation!