Thomas, Alon, Thanks for the suggestions! I will look into these and see if it looks like they could work for what I am trying to do. Jim On 12/19/2018 04:50 AM, Thomas Calderon wrote: > As one of the dev of it, I can also recommend Caml Crush, a PKCS#11 > filtering proxy [1] as a solution that works well under both tcp and unix > domain sockets, it is packaged for Debian. > I have tested this approach in the past, redirecting the server socket > through SSH and using our client library through the tunnel worked fine. > > Cheers, > > Thomas > > [1]: https://github.com/caml-pkcs11/caml-crush > > > > On Wed, 19 Dec 2018, 06:32 Alon Bar-Lev <alon.barlev@xxxxxxxxx wrote: > >> On Wed, Dec 19, 2018 at 3:03 AM mailto428496 <mailto628496@xxxxxxx> wrote: >>> Alon, >>> >>> >>> On 12/18/2018 06:52 PM, Alon Bar-Lev wrote: >>>> OK... So you have an issue... >>>> >>>> First, you need to delegate your smartcard to remote machine, probably >>>> using unix socket redirection managed by openssh. This can be done in >>>> many levels... >>>> 1. Delegate USB device, this will enable only exclusive usage of the >>>> smartcard by remote machine. >>>> 2. Delegate PC/SC, this will enable sharing the reader between local >>>> and remote machines, rdesktop is using this method. >> Check this[1] out, openssh now supports redirecting unix domain socket. >> >> [1] >> https://ludovicrousseau.blogspot.com/2010/11/pcsc-client-and-server-on-two-different.html >> >>>> 3. Delegate PKCS#11, this is the preferred method, however, there is >>>> no maintained solution to do so. >>>> 4. Delegate the ssh-agent and implement a minimal PKCS#11 provider on >>>> top to support PKINIT requirements. >>>> 5. If your card is gpg supported, use gpg-agent as ssh-gent and >>>> delegate gpg-agent to remote and use scute[1] as PKCS#11 provider, >>>> however, scute is unmaintained. >>> I agree that number 3 would be preferred. My hope was that maybe this >>> would be something that the OpenSSH group would be interested in >>> implementing / supporting as a future feature, but it sounds like there >>> aren't currently a lot of people waiting in line (Or it could be a >>> feature that a good number of people would like but just don't realize >>> it ;) (not everyone realizes/considers that PKINIT is possible for >>> smartcard auth, at least based on my observations). I could imagine >>> this being of interest to anyone with a kerberos/AD infrastructure and >>> using smartcards (which is probably a good number) and even if they are >>> not using kerberos tickets for auth (not everyone is) but still have AD >>> and want to better centralize control of SSH smartcard auth. >> This belongs to device remote access and not directly to openssh. The >> softhsm[1] project or the p11-kit[2] to implement remote access to >> PKCS#11, as it is the best software based PKCS#11 implementation. What >> you seek is a PKCS#11 proxy module that serialized everything via a >> socket and a stub that reads socket and call a real PKCS#11 >> implementation. >> >> Please look if [3] helps. >> >> [1] https://www.opendnssec.org/softhsm/ >> [2] https://p11-glue.github.io/p11-glue/p11-kit.html >> [3] https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html >> >>>> The problem is that non of these methods have a good solution... But >>>> once you have done that, you can use PKINIT at remote to access your >>>> local smartcard. >>>> >>>> If you choose to implement minimal PKCS#11 on top of ssh-agent you >>>> should use file based X.509 certificate to perform the signature. >>>> Actually, it once supported that when Roumen Petrov and I worked on >>>> the PKCS#11 implementation for OpenSSH which was not merged >>>> eventually, now I am unsure if the agent is patched to allow that[2], >>>> you can check this out maybe the patched agent enables you to perform >>>> access the X.509 certificate as well, so you can implement a nice >>>> provider on top of the patched ssh-agent. >>> Having it work with the agent would be nice too. >>> >>> Anyway, I wanted to toss this out there. Such functionality would >>> certainly help us a lot but I know that there would need to be >>> sufficient interest in order for such a thing to get into the mainstream. >>> >>> >>> Jim >>> >>>> On Wed, Dec 19, 2018 at 1:31 AM mailto428496 <mailto628496@xxxxxxx> >> wrote: >>>>> Alon, >>>>> >>>>> I should have provided more background. You are assuming that I could >>>>> perform the PKINIT prior to connecting to the SSH server. In this >> case >>>>> (and others) there is an interest in not exposing the kerberos servers >>>>> to the world and thus someone connecting remotely would not be able to >>>>> obtain a TGT or do a PKINIT. The goal would be for SSH to handle all >>>>> the auth and only after connecting to the SSH gateway server, and >> doing >>>>> a PKINIT as part of the process, then the user would have access to >>>>> kerberos and could obtain a TGT. >>>>> >>>>> >>>>> Jim >>>>> >>>>> >>>>> On 12/18/2018 06:18 PM, Alon Bar-Lev wrote: >>>>>> Hi, >>>>>> >>>>>> Maybe I am wrong, but I believe you did not get it right. >>>>>> >>>>>> You should use PKCS#11 to perform PKINIT in order to authenticate >>>>>> against the KDC to acquire TGT. >>>>>> Then ssh can use the TGT in order to issue ticket to access remote >>>>>> sshd using GSSAPI KEX. >>>>>> >>>>>> If you like to use pam_krb5 locally on your system to issue the TGT, >>>>>> do it... it yet another method to have TGT in your user context. The >>>>>> ssh command will use the TGT (or available keytab) to interact with >>>>>> sshd, without requiring any special pam module at the remote side. >>>>>> >>>>>> You can delegate your TGT using forwarded TGT into the remote machine >>>>>> if you need to jump additional hope. >>>>>> >>>>>> In other words, kerberos is SSO technology, the PK is used at >>>>>> authentication phase only and if smartcards are being used this phase >>>>>> is performed on local machine, once TGT is available, the remaining >> of >>>>>> the interaction is kerberos only. >>>>>> >>>>>> Regards, >>>>>> Alon >>>>>> >>>>>> On Wed, Dec 19, 2018 at 1:10 AM mailto428496 <mailto628496@xxxxxxx> >> wrote: >>>>>>> I know OpenSSH currently supports PKCS11 devices (such as >> smartcards) >>>>>>> for publickey authentication, but I would love to see PKCS11 >> extended >>>>>>> further. It is currently possible to perform PKCS11 certificate >>>>>>> authentication, via pam_krb5.so (on Linux at least and likely >> something >>>>>>> similar on other *NIX) which allows smartcard auth to a Kerberos >>>>>>> (including AD) server, where a TGT can also be granted. How >> difficult >>>>>>> would it be to add functionality to OpenSSH so that it can funnel >> PKCS11 >>>>>>> certs from SSH client to server and on to PAM where it could be >> used by >>>>>>> Kerberos/PKINIT? My thought is that this is at least part way there >>>>>>> with the current PKCS11 support but I won't claim to be an expert >>>>>>> regarding the internals of what would be needed. I would think >> that a >>>>>>> number of places using smartcards (I currently work for a gov agency >>>>>>> that uses smartcards) would find this approach to have additional >>>>>>> security and management features (given real-time validation >> against a >>>>>>> kerberos/AD server) over using publickey auth (based on PKCS11) and >> also >>>>>>> having the added benefit of granting a TGT on sign-in, enabling SSO >>>>>>> (GSSAPI) to additional backend servers. >>>>>>> >>>>>>> What are thoughts on this functionality being added to OpenSSH? Am >> I >>>>>>> the first to suggest such a thing? >>>>>>> >>>>>>> >>>>>>> Jim >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssh-unix-dev mailing list >>>>>>> openssh-unix-dev@xxxxxxxxxxx >>>>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev@xxxxxxxxxxx >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
