Description of problem: When you physically remove and re-insert your smartcard, you must re-initialize your ssh-agent with: ssh-add -e /usr/lib64/opensc-pkcs11.so ssh-add -s /usr/lib64/opensc-pkcs11.so This is quite clunky. It would be nice to be able to just ask it to prompt for your PIN again to reload access to the keys. Or better yet, when trying to connect, instead of: # ssh host sign_and_send_pubkey: signing failed: agent refused operation it could prompt for the PIN. Version-Release number of selected component (if applicable): openssh-7.7p1-5.fc28.x86_64
Thank you for the bug report and your interest in the smart card support in OpenSSH. Yes, it would be very nice. I have got this in my to do list since this is currently the most painful thing of pkcs11 support in Fedora. I already have several patches related to the PKCS#11 support in OpenSSH hanging in upstream bugzilla waiting for review, but it looks like the upstream developers do not care about this part at all so hopefully we will come up with some solution at least in Fedora. The main problem here is that ssh-agent protocol [1] does not have any message to ask for the pin from the client process (other than adding the smart card itself), so it should probably have to go through this interface in case the signature fails for the removed card (will require some new signaling and logic handling this issue). Prompting for the pin just after the card insertion would be even more complicated, since it would have to be asynchronous prompt using askpass program, which might scare some users. But internally, the ssh-agent loop would have to be enhanced to monitor status of pkcs11 provider modules, waiting for insert slots events and refreshing the session. [1] https://tools.ietf.org/html/draft-miller-ssh-agent-02
I'm happy to chime in on any relevant upstream reports if that will help. Thanks for all your work on this - it's very useful.
Last time I was summarizing smart card issues in OpenSSH in the following email in context of changes we did in OpenSC, but even through the promises, there was no followup since then: https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-February/036702.html For this specific issue I just filled the following bug: https://bugzilla.mindrot.org/show_bug.cgi?id=2890
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
For the record, this was partially fault of OpenSC in combination with yubikey (assuming you were using these) too as we recently learned, but it should be fixed with latest OpenSC in Fedora. I will try to rebase this patch on top of master and try that again in coming weeks.
(In reply to Orion Poplawski from comment #0) > When you physically remove and re-insert your smartcard, you must > re-initialize your ssh-agent with: > > ssh-add -e /usr/lib64/opensc-pkcs11.so > ssh-add -s /usr/lib64/opensc-pkcs11.so > > This is quite clunky. It would be nice to be able to just ask it to prompt > for your PIN again to reload access to the keys. > > Or better yet, when trying to connect, instead of: > > # ssh host > sign_and_send_pubkey: signing failed: agent refused operation > > it could prompt for the PIN. > > Version-Release number of selected component (if applicable): > openssh-7.7p1-5.fc28.x86_64 The problem is there, - in addition that this is purely console solution, all the ksshaskpass, sshaskpass-x11 whatever there are, don't work with this as they can't supply arguments to ssh-add, only pin. A better solution would be: a) pkcs11 support should be in ssh-agent itself - it supports -P switch, but it's security filter, not the same - it never changes in practise - such klunky setting with path should not be part of user interface b) ssh-agent should use pcscd - which is the dominant card service these days - not sure how this works, are there any race conditions? Also, how does this use case work with ssh-copy-id tool? SYNOPSIS ssh-copy-id [-f] [-n] [-i [identity_file]] [-p port] [-o ssh_option] [user@]hostname ssh-copy-id -h | -? It assembles a list of one or more fingerprints and tries to log in with each key, to see if any of them are already installed. It then assembles a list of those that failed to log in, and using ssh, enables logins with those keys on the remote server. I think it would better follow UNIX philosophy if you could copy <from> <to> style. There should be some short id in ssh-add -L listing and then ssh-copy-id <key id> user As such the idea of copy-tool is good. It just needs some improvement.
(In reply to Juha Tuomala from comment #7) > b) ssh-agent should use pcscd > - which is the dominant card service these days > - not sure how this works, are there any race conditions? I take that back - opensc does use pcscd already.
(In reply to Juha Tuomala from comment #7) > (In reply to Orion Poplawski from comment #0) > > When you physically remove and re-insert your smartcard, you must > > re-initialize your ssh-agent with: > > > > ssh-add -e /usr/lib64/opensc-pkcs11.so > > ssh-add -s /usr/lib64/opensc-pkcs11.so > > > > This is quite clunky. It would be nice to be able to just ask it to prompt > > for your PIN again to reload access to the keys. > > > > Or better yet, when trying to connect, instead of: > > > > # ssh host > > sign_and_send_pubkey: signing failed: agent refused operation > > > > it could prompt for the PIN. > > > > Version-Release number of selected component (if applicable): > > openssh-7.7p1-5.fc28.x86_64 > > The problem is there, - in addition that this is purely console solution, > all the ksshaskpass, sshaskpass-x11 whatever there are, don't work with this > as they can't supply arguments to ssh-add, only pin. > > A better solution would be: > a) pkcs11 support should be in ssh-agent itself The pkcs11 support is in the ssh-agent itself. > - it supports -P switch, but it's security filter, not the same > - it never changes in practise > - such klunky setting with path should not be part of user interface This is the reason why I implemented support for pkcs11 uri couple of years back: https://bugzilla.mindrot.org/show_bug.cgi?id=2817 It is available in current Fedora and RHEL so you do not need to use paths anymore. > b) ssh-agent should use pcscd > - which is the dominant card service these days > - not sure how this works, are there any race conditions? As already said, this is already the case. But there were some race conditions in OpenSC when handling reader (yubikey is both card and reader) reinserts in recent years. > Also, how does this use case work with ssh-copy-id tool? > > SYNOPSIS > ssh-copy-id [-f] [-n] [-i [identity_file]] [-p port] [-o ssh_option] > [user@]hostname > ssh-copy-id -h | -? > > It assembles a list of one or more fingerprints and tries to log in with > each key, to see if any > of them are already installed. It then assembles a list of those that > failed to log in, and > using ssh, enables logins with those keys on the remote server. It just logs in with password and checks whether the local keys (and keys from ssh-agent) are present on the remote ~/.ssh/authorized_keys and appends the missing ones. So if the keys from pkcs11 are in agent, they should be added too. If you want to upload particular key (from agent), you need to create a local file with the public key and use -f switch. > I think it would better follow UNIX philosophy if you could copy <from> <to> > style. There should be some short id in ssh-add -L listing and then > > ssh-copy-id <key id> user > > As such the idea of copy-tool is good. It just needs some improvement. Feel free to propose improvements of ssh-copy-id to the upstream repository: https://gitlab.com/phil_hands/ssh-copy-id But it is here with this syntax for quite some time so API changes are probably not very likely to happen.
(In reply to Jakub Jelen from comment #9) > > A better solution would be: > > a) pkcs11 support should be in ssh-agent itself > > The pkcs11 support is in the ssh-agent itself. Could it have a configuration file or environment variable? We always use either opesc-pkcs1.so or onepin-pkcs11.so and I assume that latter is only used in browsers. How to solve that GUI-issue for PIN request? I don't see it possible now, as the plugin is not saved anywhere. > > - it supports -P switch, but it's security filter, not the same > > - it never changes in practise > > - such klunky setting with path should not be part of user interface > > This is the reason why I implemented support for pkcs11 uri couple of years > back: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2817 > > It is available in current Fedora and RHEL so you do not need to use paths > anymore. Thanks, I now tried that myself the first time. My uri is a bit long one. https://digisaatio.fi/wiki/PKCS_11 The reason why I'm not very happy to use ssh-keygen is that these are real PKI cards, government issued and I don't need to change them, as the name implies. Breaking that certificate on chip causes a lot of travelling and lost work hours, I'd say 500 euros worth at least. > > - not sure how this works, are there any race conditions? > > As already said, this is already the case. But there were some race > conditions in OpenSC when handling reader (yubikey is both card and reader) > reinserts in recent years. I guess they all are, visible in usb and no matter how it was implemented. But I've been trying to use it now few days again and if I get it working on shell, sometimes I can't log in with browser. > > Also, how does this use case work with ssh-copy-id tool? > It just logs in with password and checks whether the local keys (and keys > from ssh-agent) are present on the remote ~/.ssh/authorized_keys and > appends the missing ones. So if the keys from pkcs11 are in agent, they > should be added too. I need to look at it more closely. Ideally it would work from pkcs11 keys all the time without need to use files. > If you want to upload particular key (from agent), you need to create a local > file with the public key and use -f switch. Yes, it's easier to copy+paste it with mouse, I guess. > Feel free to propose improvements of ssh-copy-id to the upstream repository: > https://gitlab.com/phil_hands/ssh-copy-id > > But it is here with this syntax for quite some time so API changes are > probably not very likely to happen. It would need yet-another-registration. Certificates doesn't appear to be accepted.
(In reply to Juha Tuomala from comment #10) > (In reply to Jakub Jelen from comment #9) > > > A better solution would be: > > > a) pkcs11 support should be in ssh-agent itself > > > > The pkcs11 support is in the ssh-agent itself. > > Could it have a configuration file or environment variable? We always use > either opesc-pkcs1.so or onepin-pkcs11.so and I assume that latter is only > used in browsers. At this moment, ssh-agent does not read any configuration files. I am not sure it if should start, but that is probably more up to the discussion with openssh developers in https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > How to solve that GUI-issue for PIN request? I don't see it possible now, as > the plugin is not saved anywhere. ssh-agent can ask for confirmation using askpass programs already. Asking for a pin to refresh the session was as part of my initial proposal here: https://bugzilla.mindrot.org/show_bug.cgi?id=2890 > > > - it supports -P switch, but it's security filter, not the same > > > - it never changes in practise > > > - such klunky setting with path should not be part of user interface > > > > This is the reason why I implemented support for pkcs11 uri couple of years > > back: > > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2817 > > > > It is available in current Fedora and RHEL so you do not need to use paths > > anymore. > > Thanks, I now tried that myself the first time. My uri is a bit long one. > > https://digisaatio.fi/wiki/PKCS_11 Yeah. This prints all we know. But for using the uri, you don't need to use all the parts. It is usually enough to stick with ID, object or token label, depending on what you want to achieve. Or just use uri "pkcs11:" for everything. > The reason why I'm not very happy to use ssh-keygen is that these are real > PKI cards, government issued and I don't need to change them, as the name > implies. Breaking that certificate on chip causes a lot of travelling and > lost work hours, I'd say 500 euros worth at least. > > > > > - not sure how this works, are there any race conditions? > > > > As already said, this is already the case. But there were some race > > conditions in OpenSC when handling reader (yubikey is both card and reader) > > reinserts in recent years. > > I guess they all are, visible in usb and no matter how it was implemented. > > But I've been trying to use it now few days again and if I get it working on > shell, sometimes I can't log in with browser. Some more debugging information might be needed, but you might be hitting the following issue, which is not yet fixed in Fedora: https://github.com/OpenSC/OpenSC/issues/2199 It also depends on what driver in opensc is used. Some of them are quite robust against shared access from more application and some less. > > > Also, how does this use case work with ssh-copy-id tool? > > > It just logs in with password and checks whether the local keys (and keys > > from ssh-agent) are present on the remote ~/.ssh/authorized_keys and > > appends the missing ones. So if the keys from pkcs11 are in agent, they > > should be added too. > > I need to look at it more closely. Ideally it would work from pkcs11 keys > all the time without need to use files. That would require some more love on the ssh-copy-id side as it is quite tied to files now. > > If you want to upload particular key (from agent), you need to create a local > > file with the public key and use -f switch. > > Yes, it's easier to copy+paste it with mouse, I guess. Right, but that is hard to automate :)
(In reply to Jakub Jelen from comment #11) > At this moment, ssh-agent does not read any configuration files. I am not > sure it if should start, but that is probably more up to the discussion with > openssh developers in > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev I think it should. That path is not user friendly. And I'm talking about endusers. Windows does it correctly, they have proper certificate storage and when software doesn't know what to use, a dialog is presented. As long as Linux doesn't have such (Kleopatra is only a politcal statement, Seahorse is on right track), that settings should be saved somewhere like browsers do. They have that "security tokens" section. And recent Fedora has started automating it but it's wrongly packaged as no of those packagers have access to given hardware. > > How to solve that GUI-issue for PIN request? I don't see it possible now, as > > the plugin is not saved anywhere. > > ssh-agent can ask for confirmation using askpass programs already. Asking > for a pin to refresh the session was as part of my initial proposal here: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2890 If you refer to ssh-pkcs11-helper, oddly enough it's not available on Fedora. > Yeah. This prints all we know. But for using the uri, you don't > need to use all the parts. It is usually enough to stick with ID, object or > token label, depending on what you want to achieve. Or just use uri "pkcs11:" for everything. It actually should stick on subject in question - the human, not the hardware details how it is accesssed as those change. Common Name for example stays the same across the new ID-cards. OpenVPN for example is broken in this matter. > > > > - not sure how this works, are there any race conditions? > > > > > > As already said, this is already the case. But there were some race > > > conditions in OpenSC when handling reader (yubikey is both card and reader) > > > reinserts in recent years. While using this couple days, I start feeling that it does not survive human leaving the system and coming back. I always pull my card from reader and then something goes wrong when I stick it back. Browser typically handles that removal and only asks pin again. But if I have ssh-agent active as well, I need to restart browser. > Some more debugging information might be needed, but you might be hitting the > following issue, which is not yet fixed in Fedora: > > https://github.com/OpenSC/OpenSC/issues/2199 > > It also depends on what driver in opensc is used. Some of them are quite > robust > against shared access from more application and some less. That looks like a long case, need to dig that later. To get some perspective and hands on experience what I'm experiencing, I suggest you to pick up a real PKI card: https://e-resident.gov.ee/become-an-e-resident/ https://e-resident.gov.ee/pick-up-locations/ That's government issued card regardless if your local one has one or not. It has two certs, one for authentication and one for signatures.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
(In reply to Juha Tuomala from comment #12) > [...] > > > How to solve that GUI-issue for PIN request? I don't see it possible now, as > > > the plugin is not saved anywhere. > > > > ssh-agent can ask for confirmation using askpass programs already. Asking > > for a pin to refresh the session was as part of my initial proposal here: > > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2890 > > If you refer to ssh-pkcs11-helper, oddly enough it's not available on > Fedora. $ rpm -ql openssh-clients | grep ssh-pkcs11-helper /usr/libexec/openssh/ssh-pkcs11-helper > > Yeah. This prints all we know. But for using the uri, you don't > > need to use all the parts. It is usually enough to stick with ID, object or > > token label, depending on what you want to achieve. Or just use uri "pkcs11:" for everything. > > It actually should stick on subject in question - the human, not the > hardware details how it > is accesssed as those change. Common Name for example stays the same across > the > new ID-cards. OpenVPN for example is broken in this matter. You talk about the "Subject" field of the certificate. That part of certificate is unfortunately not available in the PKCS #11 URI as defined in RFC 7512. > > > > > - not sure how this works, are there any race conditions? > > > > > > > > As already said, this is already the case. But there were some race > > > > conditions in OpenSC when handling reader (yubikey is both card and reader) > > > > reinserts in recent years. > > While using this couple days, I start feeling that it does not survive > human leaving the system and coming back. I always pull my card from reader > and then something goes wrong when I stick it back. Browser typically > handles that removal and only asks pin again. But if I have ssh-agent active > as well, I need to restart browser. Can you check with recent OpenSC? We released the 0.22.0 and updates are already in Fedora 34+. For the agent either of the patches suggested in this bug would need to be applied though. > > Some more debugging information might be needed, but you might be hitting the > > following issue, which is not yet fixed in Fedora: > > > > https://github.com/OpenSC/OpenSC/issues/2199 > > > > It also depends on what driver in opensc is used. Some of them are quite > > robust > > against shared access from more application and some less. > > That looks like a long case, need to dig that later. > > > To get some perspective and hands on experience what I'm > experiencing, I suggest you to pick up a real PKI card: > > https://e-resident.gov.ee/become-an-e-resident/ > https://e-resident.gov.ee/pick-up-locations/ > > That's government issued card regardless if your local one > has one or not. It has two certs, one for authentication > and one for signatures. I have an eID card, but our government is not that open to provide any specification or open source driver to use.
Upstream looks completely not interesting in fixing this