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
