openssh unix dev - Jan 2024 - How to get "Enter passphrase" on command line rather than GUI pop-up?

On Tue, Jan 02, 2024 at 03:52:29PM +1100, Damien Miller
wrote:
> On Mon, 1 Jan 2024, Christian Weisgerber wrote:
> 
> > Chris Green:
> > 
> > > Setting SSH_ASKPASS_REQUIRE=never in the environment on my
xubuntu
> > > 23.10 system doesn't seem to work.  I have set it:-
> > > 
> > >     chris$ env | grep SSH
> > >     SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> > >     SSH_ASKPASS_REQUIRE=never
> > 
> > What component is actually calling ssh-askpass?
> > 
> > Setting SSH_ASKPASS_REQUIRE=never has no effect for me either, but
> > that's because...
> > 
> > Jan  1 21:26:12 lorvorc ssh-agent[76961]: error: Fssh_notify_start:
> > exec(/usr/local/bin/ssh-askpass): No such file or directory
> > 
> > ... ssh-askpass is called by a previously started ssh-agent that
> > doesn't know about the new environment variable.  The fact that
> > you have SSH_AUTH_SOCK set suggests that authentication requests
> > are also forwarded to an agent in your setup.
> 
> yeah, some desktop enviornments implicitly start an agent. Often this
> isn't actually ssh-agent, but something else that speaks the agent
> protocol. Either way, they are a pain to configure because the
> configuration is usually hidden from the user and often difficult to
> disable.
> 
> Generally I find it easier to override them.
> 
My xubuntu is actually running ssh-agent:-

    chris       2549    1543  0 Jan01 ?        00:00:00 /usr/bin/ssh-agent -D -a
/run/user/1000/keyring/.ssh

It's started by gnome-keyring-daemon which is handy because it uses my
login password to unlock my default passphrase, thus I don't need to
enter a passphrase explicitly when running my GUI desktop.

It's only because I want to use a *different* key/passphrase pair for
some systems that I have hit this issue of ssh-agent using a GUI
pop-up to ask for a passphrase.

Do SSH_ASKPASS and SSH_ASKPASS_REQUIRE affect ssh-agent directly?
There's nothing in the man page indicating this.

There must be *something* in the environment that affects this because
I'm seeing two different ways of asking for the passphrase on the same
screen.  The only difference is that one is a simple terminal window
running on my system and the other is one where I have used ssh to
connect to a remote system and then ssh again back to the 'home'
system.  The local system window gets the GUI pop-up the 'two ssh'
window asks for the passphrase in the terminal.

I can even 'ssh localhost' and then the ssh to the remote asks for the
passphrase in the terminal window as I want it!  This does seem a
rather OTT workaround though! :-)

-- 
Chris Green

> 
> There must be *something* in the environment that affects this because
> I'm seeing two different ways of asking for the passphrase on the same
> screen.  The only difference is that one is a simple terminal window
> running on my system and the other is one where I have used ssh to
> connect to a remote system and then ssh again back to the 'home'
> system.  The local system window gets the GUI pop-up the 'two ssh'
> window asks for the passphrase in the terminal.
> 
I think I have it! I need to unset SSH_AUTH_SOCK, that's all that's
needed.  See:-

    chris$ ssh -i backup_id_rsa backup
[here the pop-up appears and I cancel it]
    sign_and_send_pubkey: signing failed for RSA "backup_id_rsa" from
    agent: agent refused operation
    chris at backup's password: 

    chris$ env | grep SSH
    SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
    SSH_ASKPASS_REQUIRE=never
    chris$ unset SSH_AUTH_SOCK
    chris$ ssh -i backup_id_rsa backup
    Enter passphrase for key 'backup_id_rsa': 
    chris at backup$ 

So the SSH_ASKPASS etc. are irrelevant for my set-up.  I thought I'd
tried unsetting SSH_AUTH_SOCK before but obviously I hadn't, I guess
the need to specify the key file is a result of not having that but
it's not a problem for me really.

-- 
Chris Green

On 02.01.24 10:37, Chris Green wrote:
> It's started by gnome-keyring-daemon which is handy because it uses my
> login password to unlock my default passphrase, thus I don't need to
> enter a passphrase explicitly when running my GUI desktop.
> 
> It's only because I want to use a *different* key/passphrase pair for
> some systems that I have hit this issue of ssh-agent using a GUI
> pop-up to ask for a passphrase.
Now *that* sounds like the practical thing to do is to have only the 
shells/terminals used for *those* tasks decoupled from your agent 
running centrally in the background. (Which, as you already discovered, 
can be done by unsetting $SSH_AUTH_SOCK in those shells.)
> Do SSH_ASKPASS and SSH_ASKPASS_REQUIRE affect ssh-agent directly?
> There's nothing in the man page indicating this.
I'd guess that they do, but that's irrelevant: Since the agent is not 
running in a shell/terminal, it *cannot* ask you for the passphrase on 
any command line instead, much less the one you're running the
"ssh" from.

You could instead control the agent's behaviour by un- and reloading 
privkeys with "ssh-add" before "ssh"ing, but that's
hardly a UX improvement.
> I guess the need to specify the key file is a result of [...]
OpenSSH will autoload keypairs from a number of defined pathes, but what 
seems to be the one you're using here ($HOME/backup_id_rsa) is not one 
of them, so you'll always have to point your login procedure at that 
file *somehow/-time*.

(In fact, having additional keypairs at the default pathes might be 
detrimental if you want your "ssh" to fall back to a specified one, 
because ssh will try them automatically, every time ssh asks sshd "would 
you be willing to accept *this* keypair?" counts as a failed login 
attempt (long-standing bug), and sshd limits the number of attempts 
it'll let the client have in the one TCP connection (MaxAuthTries config).)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240103/182fe017/attachment.p7s>