bug#49714: 28.0.50; TRAMP burns CPU and has insufficient user reporting when using xxxx-sk SSH keys

[Michael Albinus <michael.albinus@gmx.de>]

Dima Kogan <dima@secretsauce.net> writes:

> Hi.

Hi Dima,

> I have a yubikey, a hardware encryption device. For the purposes of SSH,
> the SSH private key is split betweek a file on disk (.ssh/id_ed25519_sk)
> and some data on the yubikey.

Great! I'm planning for a while to implement support of yubikey, but I
never started to buy a device. I herewith declare you as my tester :-)

> When logging into an SSH server, the
> interaction generally looks like this:
>
>   client$ ssh ADDRESS
>
>   Enter passphrase for key '/home/dima/.ssh/id_ed25519_sk':
>   [the user enters the passphrase; not echoed to the console]
>
>   Confirm user presence for key ED25519-SK XXXXXXXXXXXXXXX
>   [the user physically touches the yubikey with their finger]
>
>   server$
>   [we are logged-in]

Good. This should be sufficient information.

> Emacs now spins the CPU, saying nothing. Internally, ssh is asking for
> the user to touch the yubikey, but TRAMP is not communicating this
> information. I know I should touch the yubikey, and if I do that, TRAMP
> succeeds. There are two bugs here:
>
> 1. Emacs should not be spinning the CPU. This is actually an old bug. I
>    usually see this with normal SSH connections, but it only happens
>    during the login sequence, which isn't very long. In THIS case the
>    login sequence could be longer. In any case, we shouldn't be
>    spinning.

Not so simple. Tramp is in a loop, reading the process output, and
checking, whether there is something it has to handle (for example,
password requests). This loop runs until Tramp detects the remote shell
prompt.

> 2. Emacs should relay whatever ssh is saying (i.e. "Confirm user
>    presence...") to the user

I've implemented this for yubikey, pushed to master. Could you pls try?

Showing everything during the login handshake wouldn't be helpful, Tramp
is doing TRT in the background for the vast majority of actions.

> Thanks!

Best reagards, Michael.