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

From: Michael Albinus <[email-masked]>
Date: Wed, 28 Jul 2021 22:07:06 +0200

Dima Kogan <[email-masked]> writes:

Hi Dima,

>> Well, while you see the message, Tramp is looping with
>> accept-process-output in order to check, whether the yubikey has been
>> pressed. This is not different from everything else Tramp does, until
>> the remote shell prompt has been detected. So I don't see what we
>> could do otherwise ...
>
> I understand this argument. However, as a user, I would fully expect
> emacs to behave the same way while it's waiting for the passphrase as it
> does when waiting for me to touch the yubikey. Currently the passphrase
> input stage feels normal, while the wait-for-touch stage feels frozen.
> On a deeper level, in both cases we're waiting for some specific data to
> come from an OS file descriptor: either something ultimately connected
> to the keyboard, or the ssh process. Maybe this isn't worth the effort
> to fix, but it is a problem.

I have no idea how annoying this is. I plan to buy a yubikey next days,
this will give me the chance to play with. And maybe to fix it.

>> Btw, there is a timeout of 30 seconds. When you don't press the
>> yubikey during this time, Tramp shall cancel the authentication
>> process. Perhaps you could give this also a short test?
>
> Yes. Let me do that later today. The passphrase query itself (from ssh,
> unrelated to emacs) has some timeout too, which maybe expires before 30
> sec. I will check.

Thanks!

> Thanks so much for implementing this!

Best regards, Michael.