Re: Solaris 9 latest OEM SSH + pam_krb5.so.1 - Kerberos

This is a discussion on Re: Solaris 9 latest OEM SSH + pam_krb5.so.1 - Kerberos ; Did you add the session and account entries to the pam.conf for sshd-kdbint? Pam will use the other sesison and account instead, and it most likely does not have pam_krb5 listed. Jeff Blaine wrote: > Douglas E. Engert wrote: >> ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: Solaris 9 latest OEM SSH + pam_krb5.so.1

  1. Re: Solaris 9 latest OEM SSH + pam_krb5.so.1

    Did you add the session and account entries to the pam.conf
    for sshd-kdbint? Pam will use the other sesison and account instead,
    and it most likely does not have pam_krb5 listed.

    Jeff Blaine wrote:
    > Douglas E. Engert wrote:
    >> Jeff Blaine wrote:
    >>> Does anyone have a guess as to what I am doing wrong?
    >>>
    >>> MIT Kerberos 1.5.1

    >> Where is MIT Kerberos 1.5.1 used in this?

    >
    > The KDC.
    >
    >> You say you are using the Solaris sshd, and since the
    >> pam.conf file does not give a path for the pam_krb5
    >> it would use the Solaris version in /usr/lib/secrity/pam_krb5.so
    >> which would use the Solaris version of Kerberos.

    >
    > That's the only version on disk. I have no other pam_krb5.
    >
    >> I assume you are trying to use a pam_krb5 which will use
    >> the MIT Kerberos 1.5.1? Note the the e-types in the request
    >> below are (3 1) which are both DES.

    >
    > That's a separate issue I don't want to address just yet.
    >
    >>> Solaris 9 OEM SSH (latest patch cluster) with
    >>> 'PAMAuthenticationViaKBDInt yes' and a pam.conf
    >>> as such (which clearly gets hit):
    >>>
    >>> # Start pam.conf snippet
    >>> sshd-kbdint auth requisite pam_authtok_get.so.1
    >>> sshd-kbdint auth required pam_dhkeys.so.1
    >>> sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    >>> sshd-kbdint auth required pam_unix_auth.so.1
    >>> # End of pam.conf snippet
    >>>
    >>> adm # ssh -vvv -l jblaine test.foo.com
    >>> ...
    >>> debug1: Next authentication method: keyboard-interactive
    >>> debug2: userauth_kbdint
    >>> debug2: we sent a keyboard-interactive packet, wait for reply
    >>> debug2: input_userauth_info_req
    >>> debug2: input_userauth_info_req: num_prompts 1
    >>> Password:
    >>> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
    >>> Connection closed by 192.168.168.100
    >>> debug1: Calling cleanup 0x47d2c(0x0)
    >>> adm #
    >>>
    >>> debug.log:
    >>>
    >>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 655841 auth.debug]
    >>> PAM-KRB5 (auth): pam_sm_authenticate flags=0
    >>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 549540 auth.debug]
    >>> PAM-KRB5 (auth): attempt_krb5_auth: start: user='jblaine'
    >>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 179272 auth.debug]
    >>> PAM-KRB5 (auth): attempt_krb5_auth: krb5_get_init_creds_password
    >>> returns: SUCCESS
    >>>
    >>> krb5kdc.log:
    >>>
    >>> Jan 09 20:04:13 test.foo.com krb5kdc[445](info): AS_REQ (2 etypes
    >>> {3 1}) 192.168.168.100: ISSUE: authtime 1168391053, etypes {rep=3
    >>> tkt=16 ses=1}, jblaine@JBTEST for krbtgt/JBTEST@JBTEST
    >>> ________________________________________________
    >>> Kerberos mailing list Kerberos@mit.edu
    >>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>
    >>>

    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Solaris 9 latest OEM SSH + pam_krb5.so.1

    > Do you have a sshd-kbdint session pam_unix.so.1
    > The other entries are only used if there are no entries
    > for service.


    Here's everything (so, no):

    sshd-kbdint auth requisite pam_authtok_get.so.1
    sshd-kbdint auth required pam_dhkeys.so.1
    sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    sshd-kbdint auth required pam_unix_auth.so.1
    sshd-kbdint account optional pam_krb5.so.1 debug
    sshd-kbdint session optional pam_krb5.so.1 debug
    sshd-kbdint password optional pam_krb5.so.1 debug

    Adding:

    sshd-kbdint session required pam_unix.so.1

    Resulting in:

    sshd-kbdint auth requisite pam_authtok_get.so.1
    sshd-kbdint auth required pam_dhkeys.so.1
    sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    sshd-kbdint auth required pam_unix_auth.so.1
    #
    sshd-kbdint account optional pam_krb5.so.1 debug
    sshd-kbdint session required pam_unix.so.1
    sshd-kbdint session optional pam_krb5.so.1 debug
    sshd-kbdint password optional pam_krb5.so.1 debug

    Gives me the same SSH results and the same info in my logs
    as before.

    > See the man page on pam_krb5. It shows for session,
    > pam_krb5 and pam_unix.
    >
    >
    > (We use the OpenSSH and MIT Kerberos and older heavily modified
    > pam_krb5 on Solaris 9 but use the Solaris sshd, pam_krb5 and
    > Kerberos on Solaris 10.)
    >
    >>
    >> Douglas E. Engert wrote:
    >>> Did you add the session and account entries to the pam.conf
    >>> for sshd-kdbint? Pam will use the other sesison and account instead,
    >>> and it most likely does not have pam_krb5 listed.
    >>>
    >>> Jeff Blaine wrote:
    >>>> Douglas E. Engert wrote:
    >>>>> Jeff Blaine wrote:
    >>>>>> Does anyone have a guess as to what I am doing wrong?
    >>>>>>
    >>>>>> MIT Kerberos 1.5.1
    >>>>> Where is MIT Kerberos 1.5.1 used in this?
    >>>> The KDC.
    >>>>
    >>>>> You say you are using the Solaris sshd, and since the
    >>>>> pam.conf file does not give a path for the pam_krb5
    >>>>> it would use the Solaris version in /usr/lib/secrity/pam_krb5.so
    >>>>> which would use the Solaris version of Kerberos.
    >>>> That's the only version on disk. I have no other pam_krb5.
    >>>>
    >>>>> I assume you are trying to use a pam_krb5 which will use
    >>>>> the MIT Kerberos 1.5.1? Note the the e-types in the request
    >>>>> below are (3 1) which are both DES.
    >>>> That's a separate issue I don't want to address just yet.
    >>>>
    >>>>>> Solaris 9 OEM SSH (latest patch cluster) with
    >>>>>> 'PAMAuthenticationViaKBDInt yes' and a pam.conf
    >>>>>> as such (which clearly gets hit):
    >>>>>>
    >>>>>> # Start pam.conf snippet
    >>>>>> sshd-kbdint auth requisite pam_authtok_get.so.1
    >>>>>> sshd-kbdint auth required pam_dhkeys.so.1
    >>>>>> sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    >>>>>> sshd-kbdint auth required pam_unix_auth.so.1
    >>>>>> # End of pam.conf snippet
    >>>>>>
    >>>>>> adm # ssh -vvv -l jblaine test.foo.com
    >>>>>> ...
    >>>>>> debug1: Next authentication method: keyboard-interactive
    >>>>>> debug2: userauth_kbdint
    >>>>>> debug2: we sent a keyboard-interactive packet, wait for reply
    >>>>>> debug2: input_userauth_info_req
    >>>>>> debug2: input_userauth_info_req: num_prompts 1
    >>>>>> Password:
    >>>>>> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
    >>>>>> Connection closed by 192.168.168.100
    >>>>>> debug1: Calling cleanup 0x47d2c(0x0)
    >>>>>> adm #
    >>>>>>
    >>>>>> debug.log:
    >>>>>>
    >>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 655841 auth.debug]
    >>>>>> PAM-KRB5 (auth): pam_sm_authenticate flags=0
    >>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 549540 auth.debug]
    >>>>>> PAM-KRB5 (auth): attempt_krb5_auth: start: user='jblaine'
    >>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 179272 auth.debug]
    >>>>>> PAM-KRB5 (auth): attempt_krb5_auth: krb5_get_init_creds_password
    >>>>>> returns: SUCCESS
    >>>>>>
    >>>>>> krb5kdc.log:
    >>>>>>
    >>>>>> Jan 09 20:04:13 test.foo.com krb5kdc[445](info): AS_REQ (2 etypes
    >>>>>> {3 1}) 192.168.168.100: ISSUE: authtime 1168391053, etypes {rep=3
    >>>>>> tkt=16 ses=1}, jblaine@JBTEST for krbtgt/JBTEST@JBTEST
    >>>>>> ________________________________________________
    >>>>>> Kerberos mailing list Kerberos@mit.edu
    >>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>>
    >>>>>>
    >>>> ________________________________________________
    >>>> Kerberos mailing list Kerberos@mit.edu
    >>>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>
    >>>>

    >> ________________________________________________
    >> Kerberos mailing list Kerberos@mit.edu
    >> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>
    >>

    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Solaris 9 latest OEM SSH + pam_krb5.so.1

    SOLUTION:

    Solaris does strict TGT checking.

    Sun's recommended solution to me was to set the following
    to false:

    verify_ap_req_nofail [true | false]
    If true, the local keytab file (/etc/krb5/krb5.keytab)
    must contain an entry for the local host principal,
    for example, host/foo.bar.com@FOO.COM. This entry is
    needed to verify that the TGT requested was issued by
    the same KDC that issued the key for the host princi-
    pal. If undefined, the behavior is as if this option
    were set to true. Setting this value to false leaves
    the system vulnerable to DNS spoofing attacks. This
    parameter may be in the [realms] section to set it on
    a per-realm basis, or it may be in the [libdefaults]
    section to make it a network-wide setting for all
    realms.

    Now...

    1. Setting it to false solves the problem.

    2. My test box (single) has no DNS resolution working for this
    host. That is, test.foo.com does not resolve forward or
    backward. This was not a problem with any part of my KDC
    work from what I can tell. I used Russ Alberry's pam_krb5.so
    just fine...

    3. My /etc/krb5/krb5.keytab *does* have (and has always had)
    entries for both host/test.foo.com@JBTEST and
    host/192.168.168.100@JBTEST

    So...

    How much of a real "solution" that is from Sun is debatable,
    but there's the summary.

    Jeff Blaine wrote:
    >> Do you have a sshd-kbdint session pam_unix.so.1
    >> The other entries are only used if there are no entries
    >> for service.

    >
    > Here's everything (so, no):
    >
    > sshd-kbdint auth requisite pam_authtok_get.so.1
    > sshd-kbdint auth required pam_dhkeys.so.1
    > sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    > sshd-kbdint auth required pam_unix_auth.so.1
    > sshd-kbdint account optional pam_krb5.so.1 debug
    > sshd-kbdint session optional pam_krb5.so.1 debug
    > sshd-kbdint password optional pam_krb5.so.1 debug
    >
    > Adding:
    >
    > sshd-kbdint session required pam_unix.so.1
    >
    > Resulting in:
    >
    > sshd-kbdint auth requisite pam_authtok_get.so.1
    > sshd-kbdint auth required pam_dhkeys.so.1
    > sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    > sshd-kbdint auth required pam_unix_auth.so.1
    > #
    > sshd-kbdint account optional pam_krb5.so.1 debug
    > sshd-kbdint session required pam_unix.so.1
    > sshd-kbdint session optional pam_krb5.so.1 debug
    > sshd-kbdint password optional pam_krb5.so.1 debug
    >
    > Gives me the same SSH results and the same info in my logs
    > as before.
    >
    >> See the man page on pam_krb5. It shows for session,
    >> pam_krb5 and pam_unix.
    >>
    >>
    >> (We use the OpenSSH and MIT Kerberos and older heavily modified
    >> pam_krb5 on Solaris 9 but use the Solaris sshd, pam_krb5 and
    >> Kerberos on Solaris 10.)
    >>
    >>>
    >>> Douglas E. Engert wrote:
    >>>> Did you add the session and account entries to the pam.conf
    >>>> for sshd-kdbint? Pam will use the other sesison and account instead,
    >>>> and it most likely does not have pam_krb5 listed.
    >>>>
    >>>> Jeff Blaine wrote:
    >>>>> Douglas E. Engert wrote:
    >>>>>> Jeff Blaine wrote:
    >>>>>>> Does anyone have a guess as to what I am doing wrong?
    >>>>>>>
    >>>>>>> MIT Kerberos 1.5.1
    >>>>>> Where is MIT Kerberos 1.5.1 used in this?
    >>>>> The KDC.
    >>>>>
    >>>>>> You say you are using the Solaris sshd, and since the
    >>>>>> pam.conf file does not give a path for the pam_krb5
    >>>>>> it would use the Solaris version in /usr/lib/secrity/pam_krb5.so
    >>>>>> which would use the Solaris version of Kerberos.
    >>>>> That's the only version on disk. I have no other pam_krb5.
    >>>>>
    >>>>>> I assume you are trying to use a pam_krb5 which will use
    >>>>>> the MIT Kerberos 1.5.1? Note the the e-types in the request
    >>>>>> below are (3 1) which are both DES.
    >>>>> That's a separate issue I don't want to address just yet.
    >>>>>
    >>>>>>> Solaris 9 OEM SSH (latest patch cluster) with
    >>>>>>> 'PAMAuthenticationViaKBDInt yes' and a pam.conf
    >>>>>>> as such (which clearly gets hit):
    >>>>>>>
    >>>>>>> # Start pam.conf snippet
    >>>>>>> sshd-kbdint auth requisite pam_authtok_get.so.1
    >>>>>>> sshd-kbdint auth required pam_dhkeys.so.1
    >>>>>>> sshd-kbdint auth sufficient pam_krb5.so.1 debug try_first_pass
    >>>>>>> sshd-kbdint auth required pam_unix_auth.so.1
    >>>>>>> # End of pam.conf snippet
    >>>>>>>
    >>>>>>> adm # ssh -vvv -l jblaine test.foo.com
    >>>>>>> ...
    >>>>>>> debug1: Next authentication method: keyboard-interactive
    >>>>>>> debug2: userauth_kbdint
    >>>>>>> debug2: we sent a keyboard-interactive packet, wait for reply
    >>>>>>> debug2: input_userauth_info_req
    >>>>>>> debug2: input_userauth_info_req: num_prompts 1
    >>>>>>> Password:
    >>>>>>> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
    >>>>>>> Connection closed by 192.168.168.100
    >>>>>>> debug1: Calling cleanup 0x47d2c(0x0)
    >>>>>>> adm #
    >>>>>>>
    >>>>>>> debug.log:
    >>>>>>>
    >>>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 655841 auth.debug]
    >>>>>>> PAM-KRB5 (auth): pam_sm_authenticate flags=0
    >>>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 549540 auth.debug]
    >>>>>>> PAM-KRB5 (auth): attempt_krb5_auth: start: user='jblaine'
    >>>>>>> Jan 9 20:04:13 test.foo.com sshd[462]: [ID 179272 auth.debug]
    >>>>>>> PAM-KRB5 (auth): attempt_krb5_auth: krb5_get_init_creds_password
    >>>>>>> returns: SUCCESS
    >>>>>>>
    >>>>>>> krb5kdc.log:
    >>>>>>>
    >>>>>>> Jan 09 20:04:13 test.foo.com krb5kdc[445](info): AS_REQ (2 etypes
    >>>>>>> {3 1}) 192.168.168.100: ISSUE: authtime 1168391053, etypes {rep=3
    >>>>>>> tkt=16 ses=1}, jblaine@JBTEST for krbtgt/JBTEST@JBTEST
    >>>>>>> ________________________________________________
    >>>>>>> Kerberos mailing list Kerberos@mit.edu
    >>>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>>>
    >>>>>>>
    >>>>> ________________________________________________
    >>>>> Kerberos mailing list Kerberos@mit.edu
    >>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>
    >>>>>
    >>> ________________________________________________
    >>> Kerberos mailing list Kerberos@mit.edu
    >>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>
    >>>

    >>

    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Solaris 9 latest OEM SSH + pam_krb5.so.1



    On Friday, January 19, 2007 04:05:40 PM -0500 Jeff Blaine
    wrote:

    > Setting this value to false leaves
    > the system vulnerable to DNS spoofing attacks.


    This somewhat understates the problem, and IMHO doesn't do a very good job
    of describing what is going on here. Basically, the idea is that if you
    are going to let a user log in by typing his Kerberos password, you want to
    be sure the resulting TGT was issued by a real TGT. The way you do this is
    by getting a service ticket for some service whose key you know, and
    checking that the ticket is valid.

    Setting this option to false disables that check, which means that a user
    can log in by putting a fake KDC on the network typing a username and
    password, and arranging for his fake KDC's response to reach you before the
    real one. This often isn't very hard, especially if the user has physical
    access to the machine's network connection.

    The "DNS spoofing attacks" referred to in the documentation are on the
    lookup of the KDC's address - one way to insert a fake KDC is to convince
    your machine to send its KDC requests to the wrong IP address. But there
    are plenty of other attacks which do not involve DNS and are often
    available to an attacker trying to log in on the console of a machine.



    > 3. My /etc/krb5/krb5.keytab *does* have (and has always had)
    > entries for both host/test.foo.com@JBTEST and
    > host/192.168.168.100@JBTEST


    Is JBTEST configured as the default realm in krb5.conf?
    Do you have a domain_realm section mapping test.foo.com to JBTEST?
    Is the krb5.conf file in the right place?


    -- Jeff
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Solaris 9 latest OEM SSH + pam_krb5.so.1

    Jeffrey Hutzelman wrote:
    > On Friday, January 19, 2007 04:05:40 PM -0500 Jeff Blaine
    > wrote:
    >
    >> Setting this value to false leaves
    >> the system vulnerable to DNS spoofing attacks.

    >
    > This somewhat understates the problem, and IMHO doesn't do a very good
    > job of describing what is going on here. Basically, the idea is that if
    > you are going to let a user log in by typing his Kerberos password, you
    > want to be sure the resulting TGT was issued by a real TGT. The way you
    > do this is by getting a service ticket for some service whose key you
    > know, and checking that the ticket is valid.
    >
    > Setting this option to false disables that check, which means that a
    > user can log in by putting a fake KDC on the network typing a username
    > and password, and arranging for his fake KDC's response to reach you
    > before the real one. This often isn't very hard, especially if the user
    > has physical access to the machine's network connection.
    >
    > The "DNS spoofing attacks" referred to in the documentation are on the
    > lookup of the KDC's address - one way to insert a fake KDC is to
    > convince your machine to send its KDC requests to the wrong IP address.
    > But there are plenty of other attacks which do not involve DNS and are
    > often available to an attacker trying to log in on the console of a
    > machine.


    Thanks for the more detailed explanation.

    >> 3. My /etc/krb5/krb5.keytab *does* have (and has always had)
    >> entries for both host/test.foo.com@JBTEST and
    >> host/192.168.168.100@JBTEST

    >
    > Is JBTEST configured as the default realm in krb5.conf?
    > Do you have a domain_realm section mapping test.foo.com to JBTEST?
    > Is the krb5.conf file in the right place?


    Yup
    Yup
    Yup
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread