http://bugzilla.mindrot.org/show_bug.cgi?id=69
astrand at lysator.liu.se changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |astrand at lysator.liu.se
------- Additional Comments From astrand at lysator.liu.se 2003-03-26 21:10
------->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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From dwmw2 at infradead.org 2003-03-26 21:29 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From markus at openbsd.org 2003-03-26 22:59 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From astrand at lysator.liu.se 2003-03-26 23:42 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
At 09:20 AM 3/27/2003 +0000, David Woodhouse wrote:>On Wed, 2003-03-26 at 20:32, Jim Knoble wrote: >> If you want a separate behavior, that request should be explicit: >> either an explicit option to ssh-askpass (e.g., 'ssh-askpass --yesno') >> or (probably better) a separate program (e.g., 'ssh-confirm'). >> >> Care to come up with a specification? > >Hmmm. We really do have to be careful about backwards compatibility. So >a separate program probably accompanied by a separate environment >variable for it (SSH_CONFIRM?) is likely to be the best way forward.You could retain compatibility without introducing a new program by having ssh invoke ssh-askpass with an environment variable hinting at the type of request. For instance, SSH_ASKPASS_PROMPT_HINT=Y might indicate that this is a yes/no prompt. An ssh-askpass program could decide to show Yes/No buttons when it saw such an environment variable setting. An ssh-askpass program would be free to ignore such a hint and always require the user to type YES in a text box, so an old ssh-askpass would work with a future ssh that supplied an SSH_ASKPASS_PROMPT_HINT, or vice versa. Also, the read_passphrase() function that calls ssh-askpass receives a flag RP_ECHO that tells it whether echoing the user's response is appropriate. It uses this information when it prompts, but not when it calls an ssh-askpass program. The same environment variable could be used to pass this information along to any ssh-askpass program that wanted to make use of it. In more detail, if an ssh-askpass program noticed an SSH_ASKPASS_PROMPT_HINT environment variable whose value contained the letter E, it could choose to enable echoing when prompting for a line of text. If such an environment variable contained a letter Y, it could choose to display a Yes/No dialog (and output "yes" or "no" on stdout, just as now). Steven Doerfler