unable to auth with yubikey

[Anthony Roberts]

Hello,

I've got a Yubikey 5 NFC and I've set it up for ssh authentication on several hosts. I've been able to auth successfully on Mac and Windows computers, however it doesn't work on Chromeos.

I've installed hterm and smart card connector. Smart card connector detects the yubikey, it shows up as "Yubico Yubikey OTP+FIDO+CCID". I've set up a profile in hterm with "--ssh-agent=gsc", and when I attempt to use it "Secure Shell App" appears in "Connected Apps". I click to allow it to use the smart card connector. However, I am never prompted for a PIN and ssh does not appear to attempt the key from the yubikey.

I added a -v to the ssh command line options and I can see it never attempts the yubikey key, and since there's no other keys available and the server is configured for pubkey only auth fails. Has anyone encountered this issue or have any idea how to further debug? Ssh -v output follows.

Loading NaCl plugin... done.

Connecting to ??????????????????...

OpenSSH_7.9p1, OpenSSL 1.0.2k  26 Jan 2017

debug1: Connecting to ??????????????????.

debug1: Connection established.

debug1: getpeername failed: No such file or directory

debug1: identity file /.ssh/id_rsa type -1

debug1: identity file /.ssh/id_rsa-cert type -1

debug1: identity file /.ssh/id_dsa type -1

debug1: identity file /.ssh/id_dsa-cert type -1

debug1: identity file /.ssh/id_ecdsa type -1

debug1: identity file /.ssh/id_ecdsa-cert type -1

debug1: identity file /.ssh/id_ed25519 type -1

debug1: identity file /.ssh/id_ed25519-cert type -1

debug1: identity file /.ssh/id_xmss type -1

debug1: identity file /.ssh/id_xmss-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.9

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002

debug1: Authenticating to ?????????????????? as '?????????'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20...@openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20...@openssh.com MAC: <implicit> compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:????????????????????

debug1: Host '??????????????????' is known and matches the ECDSA host key.

debug1: Found key in /.ssh/known_hosts:2

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: rekey after 134217728 blocks

debug1: Will attempt key: /.ssh/id_rsa 

debug1: Will attempt key: /.ssh/id_dsa 

debug1: Will attempt key: /.ssh/id_ecdsa 

debug1: Will attempt key: /.ssh/id_ed25519 

debug1: Will attempt key: /.ssh/id_xmss 

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /.ssh/id_rsa

debug1: Trying private key: /.ssh/id_dsa

debug1: Trying private key: /.ssh/id_ecdsa

debug1: Trying private key: /.ssh/id_ed25519

debug1: Trying private key: /.ssh/id_xmss

debug1: No more authentication methods to try.

??????????????????: Permission denied (publickey).

NaCl plugin exited with status code 255.

(R)econnect, (C)hoose another connection, or E(x)it?

 failed! :(

[Fabian Henneke]

Can you provide us with the type of SSH key on the YubiKey? So far, only RSA keys in the OpenPGP applet are supported, but ECDSA/EdDSA key support has already been implemented and will probably make it into the stable version soon. General support for the PIV applet is also on the way.

If you are using ssh-rsa type keys with OpenPGP, you could look for error messages in the developer console (Ctrl+Shift+J) of the Secure Shell window and post them here, potentially redacted.

[acrob...@gmail.com]

Hello,

Thanks for the reply!

The key is rsa 2048.

I've obtained the requested log, I'm attaching it. I noticed something potentially relevant:

nassh_agent_backend_gsc.js:195 GSC.requestIdentities: failed to get public key ID from reader Yubico YubiKey OTP+FIDO+CCID 00 00, skipping

-Anthony

[Fabian Henneke]

Thank you for providing the complete log!

I can see from it that the request for the ID of the authentication public key is met with a response of the type "Memory Failure" (status bytes 0x65 0x81). We have heard from users with this error before, and in their cases it came up because they were not using the OpenPGP applet on the YubiKey for storing their SSH keys, but used the PIV applet instead, which is not (yet) supported. May I ask which command/tool you used to generate/import your SSH keys?

[Anthony Roberts]

Yes, I used PIV. Your response prompted me to give OpenPGP a try and that worked as expected. Thanks!

The PIV tool I used was the yubikey-provided management tool. I didn't realize there was a distinction. I followed the OpenPGP instructions here: https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubikey-neo/

[Fabian Henneke]

The distinction is difficult to understand since it doesn't really make any difference for the use case of SSH authentication. I hope that the situation will become less confusing when PIV support lands.

[jmstep...@gmail.com]

Sorry to resurrect this thread, but I'm curious if there is a plan to implement PIV support and when that might land?

[Fabian Henneke]

PIV support is already fully implemented and in the process of being reviewed (https://chromium-review.googlesource.com/c/apps/libapps/+/757503). If you are daring enough, you could checkout the commit and try it out before it makes its way into the dev channel.

[Matt Stephenson]

That's excellent news. Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "chromium-hterm" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-hterm/3c2UnjJdIEg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-hter...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/9b29d6ab-a981-4a43-8121-c50d7104d356%40chromium.org.

[Mike Frysinger]

i don't have a time estimate for it ... Fabian has been good at shaking the trees and making us clean up/improve our tooling in general before we can merge his work ;)

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.

[spoelst...@gmail.com]

So I've occasionally been running into a weird state that gives an error message similar to the above that I haven't been able to fully reproduce, but I was able to narrow down and also discover that a Powerwash (or testing with a different Chromebook) "fixes" whatever bad state the system has gotten into.

I was receiving a similar message to what the user encountered above and I am also using a Yubikey 5 NFC, but I hadn't until recently enabled the PIV "slot" for Windows 10, but I have encountered this error both before and since.

What seems to happen is I go to use the Secure Shell App to log into my Termina/Crostini Linux VM, and if I interrupt the login after Secure Shell tries to access the Yubikey, it leaves a BAD state cached on the system. The Yubikey isn't locked out (though I could recover using the admin PIN if necessary), and like I mentioned it works fine on another Chromebook or if I Powerwash and login and set up my VM and host system again. I think I even tried blowing away the VM and reconnecting but the bad state was coming from the `nassh` javascript used by Secure Shell for accessing the Yubikey using the `--ssh-agent=gsc` option.

To make setting up a new Chromebook for development easier I have a script that prepares the SSHd in the VM to allow the SSHd server to start and asks the users whether they would like to enable it to start on boot, and then prompts them for their SSH public key (which I also give them direction on how to grab it from the Javascript console if they are using a Yubikey) and at some point I've considered maybe disabling PAM Auth and requiring PubKeyAuth only, but I'm not sure how that would interact with the LXC/Termina bootstrap/startup process yet.

On Friday, July 12, 2019 at 12:29:37 PM UTC-5, Mike Frysinger wrote:

i don't have a time estimate for it ... Fabian has been good at shaking the trees and making us clean up/improve our tooling in general before we can merge his work ;)

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromiu...@chromium.org.