Kerberos MIT SSH Solaris 9

Andrea acirulli at gmail.com
Fri Feb 8 09:59:30 EST 2008


On 7 Feb, 20:37, "Douglas E. Engert" <deeng... at anl.gov> wrote:
> Andrea wrote:
> > Hi all,
>
> > I'm experiencing some problem on kerberizing ssh on Solaris 9 with MIT
> > Kerberos,
>
> > I have the following setting:
>
> > 1. Sun Solaris 5.9
>
> > 2. MIT Kerberos KDC 1.6.3  ( I use just the kdc from the MIT Kerberos)
>
> > 3. On Kerberos client side I used the one from Solaris from the
> > following packet: SUNWkrbu
>
> > 4. Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f
>
> I don't believe the Solars 9 sshd supports GSSAPI which is what you
> are looking for. On Solaris 9 we use OpenSSH and the MIT Kerberos.
> (/usr/bin/ldd /usr/lib/ssh/sshd does not show any Kerberos or gssapi libs.)
>
If i type ldd /usr/lib/ssh/sshd I obtain following result:

root at colcascms # ldd /usr/lib/ssh/sshd
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libpam.so.1 =>   /usr/lib/libpam.so.1
        libbsm.so.1 =>   /usr/lib/libbsm.so.1
        libwrap.so.1 =>  /usr/sfw/lib/libwrap.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        libcmd.so.1 =>   /usr/lib/libcmd.so.1
        libgss.so.1 =>   /usr/lib/libgss.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libxfn.so.2 =>   /usr/lib/libxfn.so.2
        /usr/platform/SUNW,Sun-Fire-V440/lib/libmd5_psr.so.1
        /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
And then I investigate about how ssh call the library libgss (with
truss) and seems that ssh through libgss tries to obtain the ticket
credential, this is part of the truss command launched as follow truss
-u mech_krb5,libgss:: ssh user at hostaname:

-> libgss:gss_acquire_cred(0xffbff660, 0x0, 0x0, 0x116938)
open("/var/run/rpc_door/rpc_100029.1", O_RDONLY) Err#2 ENOENT open("/
var/run/rpc_door/rpc_100029.1", O_RDONLY) Err#2 ENOENT

getuid()                                        = 0 [0]
open("/tmp/krb5cc_0", O_RDONLY)                 Err#2 ENOENT
open("/tmp/krb5cc_0", O_RDONLY)                 Err#2 ENOENT
<- libgss:gss_acquire_cred() = 0x70000

It seems that this ssh supports in such a way GSS-API.

Any further suggestions??

Thanks for the precious suggesstions.

Bye

> But On Solairs 10, The Sun ssh/sshd does support GSSAPI, and works
> well with GSSAPI using the Sun Kerberos.
>
>
>
>
>
> > This is my pam.conf:
> > # PAM configuration
> > #
> > # Customized to try pam_unix, then pam_krb5
> > #
> > # Unless explicitly defined, all services use the modules
> > # defined in the "other" section.
> > #
> > # Modules are defined with relative pathnames, i.e., they are
> > # relative to /usr/lib/security/$ISA. Absolute path names, as
> > # present in this file in previous releases are still acceptable.
> > #
> > # Authentication
> > #
> > # passwd command (explicit because of a different authentication
> > module)
> > #
> > passwd  auth required           pam_passwd_auth.so.1
> > #
> > # Default definition for Authentication management
> > # Used when service name is not explicitly mentioned for
> > authentication
> > #   management
> > #
> > other   auth requisite          pam_authtok_get.so.1
> > other   auth sufficient         pam_unix_auth.so.1
> > other   auth required           pam_krb5.so.1 use_first_pass debug
> > #
> > # Account
> > #
> > # cron service (explicit because of non-usage of pam_roles.so.1)
> > #
> > cron    account required        pam_projects.so.1
> > cron    account required        pam_unix_account.so.1
> > # See notes about pam_krb5 in "other" section below
> > cron    account optional        pam_krb5.so.1 debug
> > #
> > # Default definition for Account management
> > # Used when service name is not explicitly mentioned for account
> > management
> > #
> > other   account requisite       pam_roles.so.1
> > other   account required        pam_projects.so.1
> > other   account required        pam_unix_account.so.1
> > # According to the pam_krb5 man page, this checks for password
> > expiration.
> > # I'm not sure this does anything since I've flagged it as optional.
> > # I'm not sure if I can make it required because of root.
> > other   account optional        pam_krb5.so.1 debug
> > #
> > # Session
> > #
> > # Default definition for Session management
> > # Used when service name is not explicitly mentioned for session
> > management
> > #
> > other   session optional        pam_krb5.so.1 debug
> > other   session required        pam_unix_session.so.1
> > #
> > # Password
> > #
> > # (Don't list pam_krb5 here, this section is only for root.  Regular
> > # users must use the centralized department password changing
> > mechanism.)
> > #
> > # Default definition for Password management
> > # Used when service name is not explicitly mentioned for password
> > management
> > #
> > other   password requisite      pam_authtok_get.so.1
> > other   password requisite      pam_authtok_check.so.1
> > other   password required       pam_authtok_store.so.1
> > #
>
> > I can ssh into the machine using the password from kerberos, when I
> > let in I have the two tickets (TGT and TGS), but if I try to ssh on
> > the same machine I have to retype the password, hence single sign on
> > seems not working.
>
> > Anyone can suggest me where am i wrong???
> > Is the pam.conf correct?
> > Does native Solaris ssh supports well gssapi delegation credentials??
>
> It does on Solaris 10!
>
>
>
> > My goal is to obtain single sign on with as much as possible native
> > solaris tool, with just an exception use MIT KERBEROS KDC SERVER!
>
> We do that on Solaris 10 but using Windows AD as the KDC.
>
>
>
> > Thanks in advance!
> > ________________________________________________
> > Kerberos mailing list           Kerbe... at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
>   Douglas E. Engert  <DEEng... at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444




More information about the Kerberos mailing list