Jeff King [off-list ref] writes:
export SSH_ASKPASS=whatever
# this will try the terminal first, then SSH_ASKPASS, because it is
# ssh doing the asking
git push ssh://example.com/repo.git
Sorry, you lost me here. Does "ssh example.com" consult the terminal
first and then fall back to SSH_ASKPASS environment variable?
I was under the impression that SSH_ASKPASS was to either give hands-free
access to the keychain or give GUI experience so that people do not have
to type from their terminals...
# this will try SSH_ASKPASS first, then the terminal, because git is
# doing the asking
git push https://example.com/repo.git
So now I'm more convinced than ever that the order should be
GIT_ASKPASS, terminal, SSH_ASKPASS.
On Tue, Feb 14, 2012 at 02:35:23PM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
export SSH_ASKPASS=whatever
# this will try the terminal first, then SSH_ASKPASS, because it is
# ssh doing the asking
git push ssh://example.com/repo.git
Sorry, you lost me here. Does "ssh example.com" consult the terminal
first and then fall back to SSH_ASKPASS environment variable?
Yes. Try:
SSH_ASKPASS=cat ssh example.com
where cat is any program whose running you could detect (in this case,
because cat will complain to stderr about not being able to open its
argument). And "example.com" must be something that you can actually
make an ssh connection to.
Compare with:
SSH_ASKPASS=cat setsid ssh example.com
which will realize it has no controlling tty, and fallback to
SSH_ASKPASS.
I actually find the behavior slightly annoying (because sometimes you do
have a controlling terminal, but it is not accessible or obvious to the
user). But I think it's important to be consistent, and provide
GIT_ASKPASS for people who really want to say "no, don't even bother
with the terminal".
I was under the impression that SSH_ASKPASS was to either give hands-free
access to the keychain or give GUI experience so that people do not have
to type from their terminals...
Not exactly. It's useful in two situations (in my experience):
1. A GUI program spawns an ssh tunnel, and there is no tty on which to
prompt the user.
2. Populating an ssh-agent via ssh-add during the user's login
sequence.
It doesn't work to give a GUI experience to creating a remote terminal
session, since if you have a terminal, it will always prefer to prompt
on the terminal.
-Peff