On Tue, Sep 02, 2025 at 10:31:02AM -0000, Stuart Henderson wrote: > On 2025-09-02, Robert Alessi <[email protected]> wrote: > > I wouldn't mind either but the thing is one can't assume > > login_yubikey(8) will remain in base.[1] A good reason to keep it would > > be to allow ssh login from a machine where yubikey otp can be used. > > careful with login_yubikey for ssh; there's no good way to sync the > counter files, so replay detection is only per-machine. (concretely: > if someone captures your otp from one login, they can login to other > machines using the same key until you've logged in to them too).
Actually, I've only ever used login_yubikey with ssh to log back in from a VM on the host via sshfs, but thank you for this insightful remark! That will be one more reason to toss my yubikey. I must admit that I have found not having to enter passwords very convenient. With yubikey-personalization-gui, I was able to unset slot 1 to set only slot 2 for otp. The procedure took me about 5 minutes years ago and, I must say, to unexpectedly get ccccccluufelcluublrnvrefefgebjddbedivujkndic'ed through slot 2, one really has to hold on to the key! I have just set up login_oath. For now, I'm using my phone to get the 6-digit PIN. Then, once logged in, I had the idea of doing this: #!/bin/sh cat $HOME/.totp-key | oathtool --totp -s 30 - | xclip sleep 5 xclip /dev/null This way, I have 5 secs to get new PINs that I can paste with the middle button of my thinkpad. Hardly ideal, but it's what came up this morning. > this is a shortcoming of login_yubikey(8) - other yk otp-based login > methods (e.g. using radius to auth at a central location that checks > coubters) are possible. I surmise the same shortcoming also applies to S/Key? Thanks again for the the info.
