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. 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. Regards, Alon [1] https://github.com/gpg/scute [2] https://roumenpetrov.info/secsh/index.html 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
