Secure Shell (dev) not reading PIV card for certificates

[ncbi jesse]

I am trying to connect via SSH to a server using a work-issued PIV card, but have run into some problems.  I would like to be able to do this, so as to put together a process for more general usage and deployment to our end users.

Various details:

* ChomeOS Version 88.0.4324.153 (Official Build) (64-bit), using a pristine Google account created for this purpose.  (literally a new Chromebook out of the box, updated and cleanly rebooted)
* Secure Shell (dev) 0.39.7728.27429.

* CACKey Version 0.7.10.10

* Smart Card Connector 1.3.3.0

I can use both the card and card reader on other Linux systems without problems.

Within CACKey, I am able to read certificates, and they appear correct.  Smart Card Connector shows both the card reader, and two connected Apps:  "Secure Shell Extension (dev)" and "CACKey" 

SSH connection options are straightforward:

  Relay server options are:   --ssh-agent=gsc

  SSH Arguments:  -v -v -v

On connecting, I can see in the SSH debug logs that the certificates from the card are not offered to the server (just the default ~/.ssh/id_* files), nor is there obvious activity on the card reader itself (normally, there's a flashing light, and a short delay while the card is read).

The Smart Card Connector debug logs show that the reader is opened, but that there is a "sharing violation" message (see attached file).

Testing a bit more, including unplugging and reconnecting the reader, I get different behavior:

1. the light on the card reader flashes briefly, as if it is reading the card, but not as long as when it "works" on other hosts.

2. the SSH window freezes

3. after some time (~60s) the SSH window crashes ("Aw Snap!", error code 64000).

Smart Card Connector logs for this are attached as well.

I can't copy/paste the SSH logs (the Chrome window is frozen, then cleared), but I can try to get a screenshot if that would help.  (the last SSH message is:  "debug1: rekey in after 4294967296 blocks")

Downgrading to the non-Dev version of the SSH App (0.39) has the same behavior.

Is there something obvious that I'm missing, or anything else to try?  

I'm happy to help debug the issue in detail.

Thanks,

[Maksim Ivanov]

Hello,

Your finding seems to be correct - the "Sharing violation" is most likely the cause of the troubles. Basically, the Secure Shell application requires exclusive access to the card, which is not possible simultaneously with the CACKey application that keeps an open connection to the card. The "Sharing violation" error is the expected behavior in this situation.

As a workaround, you can try disabling the CACKey app while using Secure Shell.

We can also think about whether the exclusive access is really required for the Secure Shell. +Fabian Henneke who actually asked this question in the original code review (https://chromium-review.googlesource.com/c/apps/libapps/+/550116/5..23/nassh/js/nassh_agent_backend_gsc.js#b919), but there were no opinions on this topic.

Maksim

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/778339f4-f7da-498e-a26d-9e7b01682337n%40chromium.org.

[ncbi jesse]

Thanks for the reply.

It seems simple enough:  I have no specific need for CACKey, or any similar tools.  I will uninstall it, and try again.

The actual *crash* however, is something else.  I haven't rebooted (yet), but at this point, any attempt to to connect using the card will hang and crash.  Connections that do not require accessing the card read appear to work fine.

[Fabian Henneke]

My personal opinion nowadays is that Secure Shell should not request exclusive access to the smart card. Since all applications that are allowed to access the smart card through the connector are individually trusted, non-exclusive access would not cross any security boundaries. If users want to ensure that e.g. entering the PIN once only unlocks a single operation on the card, they could rely on a hardware token with a button.

+Mike Frysinger What do you think, should we switch the smart card backend of Secure Shell over to non-exclusive mode?

[Mike Frysinger]

i don't see why Secure Shell would need exclusive access, or really why exclusive access in general is a thing

-mike

[ncbi jesse]

I have removed CACKey and rebooted and the sharing violation error is gone.  I do see a log entry reading about connecting with dwShareMode=SCARD_SHARE_EXCLUSIVE, but it sounds like that is expected (for now...).  Unfortunately, that doesn't help with the hang and crash.  

Back on the Dev version of the App (0.39.7729.27364)

The SSH logs are (again) not much help: see potato quality photo of the screen (the built-in screen capture doesn't always work when the window is hung...).  I've also attached a new smart card log with two connection attempts (both fail in the same way).

Anything I can do to collect more information as to where the hang is happening?

[Neale Pickett]

I'm also getting a hang and (eventually) an "aw snap", right after the rekey message.

If I have the developer tools open, it looks like the crash is being caused by running out of memory.

[ncbi jesse]

I've created https://crbug.com/1213218 for this problem (still an issue with 0.40, and chromeos Version 90.0.4430.218.