Closed mkotsbak closed 11 years ago
So.. the problem here lies with the construction of the YubiKey and the nature of it being a USB keyboard. Usb keyboards send characters as scan-codes, these differ between keyboard layouts. So the YubiKey sends the OTP in modhex, which is a set that works among most of the qwerty like layouts. For the standard YubiKey we have no "real" solution to this except making sure your YubiKey is recognized as a qwerty device or something along those lines. For the YubiKey NEO we have a new feature where you can set the scancodes to be sent from the YubiKey, this isn't supported in the GUI yet but on the command line (see the manual for ykpersonalize, -S switch).
/klas
Ah, I see. Unfortunately I don't have a NEO so I can't test it.
You should be able to do something like what's described at https://vtluug.org/wiki/Yubikey in your x config to make the YubiKey always be mapped as qwerty.
/klas
Ah, thanks.
Just a comment: I found this to work for me on MacOS X:
http://superuser.do/yubikey-support-for-non-qwerty-keyboard-layouts-on-mac-os-x/
Would it be possible to just send all modhex scancodes in a predefined order before the actual one-time key, so the authentication server could calibrate itself to support pretty much any layout? Have I understood something wrong about the operation principle of Yubikey?
It is possible to send the modhex alphabet first (set the configuration flag send-ref) though no server/client combo that I know of has support for this. There's also https://bitbucket.org/dholth/yubikey/src which can be implemented in clients to transcode the input to standard modhex.
When using Dvorak keyboard layout, the generated keys do not work.
It is probably not so easy to support, but one idea I have is to be able to select Dvorak in the configuration. Then it could either always be used with Dvorak, or you could have one config with Dvorak and one with Qwerty.