Re: RFE: OpenSSH Support for PKCS11 Funneling to PAM for Kerberos/PKINIT

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux