Mailing List Archive

[Bug 69] Generalize SSH_ASKPASS
https://bugzilla.mindrot.org/show_bug.cgi?id=69


Damien Miller <djm@mindrot.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |djm@mindrot.org
Alias| |generalised-askpass




--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69


rumen <openssh@roumenpetrov.info> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |openssh@roumenpetrov.info




--- Comment #9 from rumen <openssh@roumenpetrov.info> 2008-08-30 02:34:35 ---
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.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69


Jim Knoble <jmknoble@pobox.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jmknoble@pobox.com




--- Comment #10 from Jim Knoble <jmknoble@pobox.com> 2008-08-30 04:40:20 ---
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?

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69





--- Comment #11 from Jim Knoble <jmknoble@pobox.com> 2008-08-30 04:45:46 ---
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)

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69





--- Comment #12 from Jim Knoble <jmknoble@pobox.com> 2008-08-30 04:48:28 ---
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

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69





--- Comment #13 from Jim Knoble <jmknoble@pobox.com> 2008-08-30 05:06:57 ---
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.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69





--- Comment #14 from Jim Knoble <jmknoble@pobox.com> 2008-09-03 04:46:41 ---
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".

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 69] Generalize SSH_ASKPASS [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=69





--- Comment #15 from Roumen Petrov <openssh@roumenpetrov.info> 2008-09-03 07:03:25 ---
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 ?

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs