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. > 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. > 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
