pam_krb5 does not get credentials when using ssh - Kerberos

This is a discussion on pam_krb5 does not get credentials when using ssh - Kerberos ; pam_krb5 gives credentials (using a 'random' cache) just fine when loging in on the local machine. However, if I log in over ssh, it does not get the krb5 tickets, though it authenticates off kerberos just fine. I am appending ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: pam_krb5 does not get credentials when using ssh

  1. pam_krb5 does not get credentials when using ssh

    pam_krb5 gives credentials (using a 'random' cache) just fine when loging
    in on the local machine. However, if I log in over ssh, it does not get
    the krb5 tickets, though it authenticates off kerberos just fine. I am
    appending my pam config for system authentication:

    #%PAM-1.0

    auth required pam_env.so
    #auth sufficient pam_krb5.so forwardable debug
    auth sufficient pam_unix.so likeauth nullok
    auth sufficient pam_krb5.so try_first_pass forwardable debug
    auth required pam_deny.so

    account sufficient pam_krb5.so debug
    account required pam_unix.so


    password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
    password sufficient pam_krb5.so use_authtok debug
    password sufficient pam_unix.so nullok md5 shadow use_authtok
    password required pam_deny.so


    session required pam_limits.so
    session optional pam_krb5.so debug
    session required pam_unix.so

    when I connect over ssh, this is what get's spit out over
    /var/log/auth.log

    Nov 8 01:02:14 bloo sshd(pam_unix)[22884]: authentication failure;
    logname= uid=0 euid=0 tty=ssh ruser= rhost=mason.gmu.edu user=andy
    Nov 8 01:02:14 bloo sshd[22884]: pam_krb5: authentication succeeds for
    `andy'
    Nov 8 01:02:14 bloo sshd[22884]: pam_krb5: pam_sm_authenticate
    returning 0 (Success)
    Nov 8 01:02:14 bloo sshd[22880]: Accepted keyboard-interactive/pam for
    andy from 129.174.1.13 port 44164 ssh2
    Nov 8 01:02:14 bloo sshd(pam_unix)[22885]: session opened for user andy
    by andy(uid=0)

    it says nothing from session pam_krb5.

    if I change pam_krb5 (in session) from optional to required, the login
    fails alltogether over ssh.

    Thanks for the help!
    --Andrew

  2. Re: pam_krb5 does not get credentials when using ssh

    On Wed, 08 Nov 2006 06:06:34 +0000, Andrew Bovill wrote:

    > pam_krb5 gives credentials (using a 'random' cache) just fine when loging
    > in on the local machine. However, if I log in over ssh, it does not get
    > the krb5 tickets, though it authenticates off kerberos just fine. I am
    > appending my pam config for system authentication:


    I forgot to mention, the sshd server I'm using is kerberized:
    OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 with kerberos support.

    --Andrew

  3. Re: pam_krb5 does not get credentials when using ssh

    Andrew Bovill wrote in
    newsan.2006.11.08.06.06.32.53163@gmail.com:

    > pam_krb5 gives credentials (using a 'random' cache) just fine when
    > loging in on the local machine. However, if I log in over ssh, it does
    > not get the krb5 tickets, though it authenticates off kerberos just
    > fine. I am appending my pam config for system authentication:
    >
    > #%PAM-1.0
    >
    > auth required pam_env.so
    > #auth sufficient pam_krb5.so forwardable debug
    > auth sufficient pam_unix.so likeauth nullok
    > auth sufficient pam_krb5.so try_first_pass forwardable debug
    > auth required pam_deny.so
    >
    > account sufficient pam_krb5.so debug
    > account required pam_unix.so
    >
    >
    > password required pam_cracklib.so difok=2 minlen=8 dcredit=2
    > ocredit=2 retry=3 password sufficient pam_krb5.so use_authtok
    > debug password sufficient pam_unix.so nullok md5 shadow
    > use_authtok password required pam_deny.so
    >
    >
    > session required pam_limits.so
    > session optional pam_krb5.so debug
    > session required pam_unix.so
    >
    > when I connect over ssh, this is what get's spit out over
    > /var/log/auth.log
    >
    > Nov 8 01:02:14 bloo sshd(pam_unix)[22884]: authentication failure;
    > logname= uid=0 euid=0 tty=ssh ruser= rhost=mason.gmu.edu user=andy
    > Nov 8 01:02:14 bloo sshd[22884]: pam_krb5: authentication succeeds
    > for `andy'
    > Nov 8 01:02:14 bloo sshd[22884]: pam_krb5: pam_sm_authenticate
    > returning 0 (Success)
    > Nov 8 01:02:14 bloo sshd[22880]: Accepted keyboard-interactive/pam
    > for andy from 129.174.1.13 port 44164 ssh2
    > Nov 8 01:02:14 bloo sshd(pam_unix)[22885]: session opened for user
    > andy by andy(uid=0)
    >
    > it says nothing from session pam_krb5.
    >
    > if I change pam_krb5 (in session) from optional to required, the login
    > fails alltogether over ssh.
    >
    > Thanks for the help!
    > --Andrew
    >


    Well, it was late and I forgot to add any of my debugging info.
    here is the output from sshd -ddd

    bloo ~ # /usr/sbin/sshd -dddDp2222
    debug2: load_server_config: filename /etc/ssh/sshd_config
    debug2: load_server_config: done config len = 401
    debug2: parse_server_config: config /etc/ssh/sshd_config len 401
    debug3: /etc/ssh/sshd_config:14 setting Protocol 2
    debug3: /etc/ssh/sshd_config:56 setting PasswordAuthentication no
    debug3: /etc/ssh/sshd_config:63 setting KerberosAuthentication yes
    debug3: /etc/ssh/sshd_config:64 setting KerberosOrLocalPasswd yes
    debug3: /etc/ssh/sshd_config:65 setting KerberosTicketCleanup yes
    debug3: /etc/ssh/sshd_config:69 setting GSSAPIAuthentication yes
    debug3: /etc/ssh/sshd_config:70 setting GSSAPICleanupCredentials yes
    debug3: /etc/ssh/sshd_config:81 setting UsePAM yes
    debug3: /etc/ssh/sshd_config:85 setting X11Forwarding yes
    debug3: /etc/ssh/sshd_config:86 setting X11DisplayOffset 10
    debug3: /etc/ssh/sshd_config:92 setting UsePrivilegeSeparation no
    debug3: /etc/ssh/sshd_config:120 setting Subsystem sftp
    /usr/lib/misc/sftp-server
    debug1: sshd version OpenSSH_4.4p1
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
    debug1: read PEM private key done: type RSA
    debug1: private host key: #0 type 1 RSA
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
    debug1: read PEM private key done: type DSA
    debug1: private host key: #1 type 2 DSA
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-dddDp2222'
    debug2: fd 3 setting O_NONBLOCK
    debug1: Bind to port 2222 on 0.0.0.0.
    Server listening on 0.0.0.0 port 2222.
    socket: Address family not supported by protocol
    debug3: fd 4 is not O_NONBLOCK
    debug1: Server will not fork when running in debugging mode.
    debug3: send_rexec_state: entering fd = 7 config len 401
    debug3: ssh_msg_send: type 0
    debug3: send_rexec_state: done
    debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
    debug1: inetd sockets after dupping: 3, 3
    Connection from 129.174.1.13 port 45276
    debug1: Client protocol version 2.0; client software version Sun_SSH_1.1
    debug1: no match: Sun_SSH_1.1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.4
    debug2: fd 3 setting O_NONBLOCK
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-
    hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-
    group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
    cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
    cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
    ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
    ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
    hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
    debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    debug2: dh_gen_key: priv key bits set: 132/256
    debug2: bits set: 1007/2048
    debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    debug2: bits set: 967/2048
    debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user andy service ssh-connection method
    none
    debug1: attempt 0 failures 0
    debug3: Trying to reverse map address 129.174.1.13.
    debug2: parse_server_config: config reprocess config len 401
    debug2: input_userauth_request: setting up authctxt for andy
    debug1: PAM: initializing for "andy"
    debug1: PAM: setting PAM_RHOST to "mason.gmu.edu"
    debug1: PAM: setting PAM_TTY to "ssh"
    debug2: input_userauth_request: try method none
    Failed none for andy from 129.174.1.13 port 45276 ssh2
    debug1: userauth-request for user andy service ssh-connection method
    keyboard-interactive
    debug1: attempt 1 failures 1
    debug2: input_userauth_request: try method keyboard-interactive
    debug1: keyboard-interactive devs
    debug1: auth2_challenge: user=andy devs=
    debug1: kbdint_alloc: devices 'pam,skey'
    debug2: auth2_challenge_start: devices pam,skey
    debug2: kbdint_next_device: devices skey
    debug1: auth2_challenge_start: trying authentication method 'pam'
    debug3: PAM: sshpam_init_ctx entering
    debug3: PAM: sshpam_thread_conv entering, 1 messages
    debug3: ssh_msg_send: type 1
    debug3: ssh_msg_recv entering
    debug3: PAM: sshpam_query entering
    debug3: ssh_msg_recv entering
    Postponed keyboard-interactive for andy from 129.174.1.13 port 45276
    ssh2
    debug2: PAM: sshpam_respond entering, 1 responses
    debug3: ssh_msg_send: type 6
    debug3: PAM: sshpam_query entering
    debug3: ssh_msg_recv entering
    debug1: do_pam_account: called
    debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)
    debug3: ssh_msg_send: type 0
    debug3: PAM: import_environments entering
    debug3: sshpam_password_change_required 0
    debug3: PAM: num env strings 0
    debug1: PAM: num PAM env strings 0
    Postponed keyboard-interactive/pam for andy from 129.174.1.13 port 45276
    ssh2
    debug2: PAM: sshpam_respond entering, 0 responses
    debug3: PAM: sshpam_free_ctx entering
    debug3: PAM: sshpam_thread_cleanup entering
    debug1: do_pam_account: called
    Accepted keyboard-interactive/pam for andy from 129.174.1.13 port 45276
    ssh2
    debug1: Entering interactive session for SSH2.
    debug2: fd 5 setting O_NONBLOCK
    debug2: fd 6 setting O_NONBLOCK
    debug1: server_init_dispatch_20
    debug1: server_input_channel_open: ctype session rchan 0 win 65536 max
    16384
    debug1: input_session_request
    debug1: channel 0: new [server-session]
    debug1: session_new: init
    debug1: session_new: session 0
    debug1: session_open: channel 0
    debug1: session_open: session 0: link with channel 0
    debug1: server_input_channel_open: confirm session
    debug1: server_input_channel_req: channel 0 request pty-req reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req pty-req
    debug1: Allocating pty.
    debug1: session_pty_req: session 0 alloc /dev/pts/3
    debug3: tty_parse_modes: SSH2 n_bytes 266
    debug3: tty_parse_modes: ospeed 38400
    debug3: tty_parse_modes: ispeed 38400
    debug3: tty_parse_modes: 1 3
    debug3: tty_parse_modes: 2 28
    debug3: tty_parse_modes: 3 127
    debug3: tty_parse_modes: 4 21
    debug3: tty_parse_modes: 5 4
    debug3: tty_parse_modes: 6 0
    debug3: tty_parse_modes: 7 0
    debug3: tty_parse_modes: 8 17
    debug3: tty_parse_modes: 9 19
    debug3: tty_parse_modes: 10 26
    debug1: Ignoring unsupported tty mode opcode 11 (0xb)
    debug3: tty_parse_modes: 12 18
    debug3: tty_parse_modes: 13 23
    debug3: tty_parse_modes: 14 22
    debug1: Ignoring unsupported tty mode opcode 16 (0x10)
    debug3: tty_parse_modes: 18 15
    debug3: tty_parse_modes: 30 0
    debug3: tty_parse_modes: 31 0
    debug3: tty_parse_modes: 32 0
    debug3: tty_parse_modes: 33 0
    debug3: tty_parse_modes: 34 0
    debug3: tty_parse_modes: 35 0
    debug3: tty_parse_modes: 36 1
    debug3: tty_parse_modes: 37 0
    debug3: tty_parse_modes: 38 1
    debug3: tty_parse_modes: 39 0
    debug3: tty_parse_modes: 40 0
    debug3: tty_parse_modes: 41 0
    debug3: tty_parse_modes: 50 1
    debug3: tty_parse_modes: 51 1
    debug3: tty_parse_modes: 52 0
    debug3: tty_parse_modes: 53 1
    debug3: tty_parse_modes: 54 1
    debug3: tty_parse_modes: 55 1
    debug3: tty_parse_modes: 56 0
    debug3: tty_parse_modes: 57 0
    debug3: tty_parse_modes: 58 0
    debug3: tty_parse_modes: 59 1
    debug3: tty_parse_modes: 60 1
    debug3: tty_parse_modes: 61 1
    debug3: tty_parse_modes: 62 0
    debug3: tty_parse_modes: 70 1
    debug3: tty_parse_modes: 71 0
    debug3: tty_parse_modes: 72 1
    debug3: tty_parse_modes: 73 0
    debug3: tty_parse_modes: 74 0
    debug3: tty_parse_modes: 75 0
    debug3: tty_parse_modes: 90 1
    debug3: tty_parse_modes: 91 1
    debug3: tty_parse_modes: 92 0
    debug3: tty_parse_modes: 93 0
    debug1: server_input_channel_req: channel 0 request shell reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req shell
    debug1: PAM: setting PAM_TTY to "/dev/pts/3"
    debug1: PAM: establishing credentials
    debug1: Setting controlling tty using TIOCSCTTY.
    debug2: fd 3 setting TCP_NODELAY
    debug2: channel 0: rfd 8 isatty
    debug2: fd 8 setting O_NONBLOCK
    debug3: fd 7 is O_NONBLOCK



    here is the output from the client with -vvv

    [abovill@mason ~]=>ssh -vvvp2222 andy@eeble.net
    Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Rhosts Authentication disabled, originating port will not be
    trusted.
    debug1: ssh_connect: needpriv 0
    debug1: Connecting to eeble.net [70.17.118.181] port 2222.
    debug1: Connection established.
    debug1: identity file /home/u1/abovill/.ssh/identity type -1
    debug1: identity file /home/u1/abovill/.ssh/id_rsa type -1
    debug1: identity file /home/u1/abovill/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.4
    debug1: match: OpenSSH_4.4 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-Sun_SSH_1.1
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
    hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug1: Failed to acquire GSS-API credentials for any mechanisms (No
    credentials were supplied, or the credentials were unavailable or
    inaccessible
    Unknown code 0
    )
    debug1: SSH2_MSG_KEXINIT sent
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 &&
    !0
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
    hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-
    cbc,blowfish-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: i-default
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-
    hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-
    group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
    cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
    cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
    cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
    ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
    ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: Peer sent proposed langtags, ctos:
    debug1: Peer sent proposed langtags, stoc:
    debug1: We proposed langtags, ctos: i-default
    debug1: We proposed langtags, stoc: i-default
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: dh_gen_key: priv key bits set: 131/256
    debug1: bits set: 1004/2048
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename
    /home/u1/abovill/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 3
    debug3: check_host_in_hostfile: filename
    /home/u1/abovill/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 3
    debug1: Host 'eeble.net' is known and matches the RSA host key.
    debug1: Found key in /home/u1/abovill/.ssh/known_hosts:3
    debug1: bits set: 1010/2048
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 &&
    !0
    debug1: newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: done: ssh_kex2.
    debug1: send SSH2_MSG_SERVICE_REQUEST
    debug2: service_accept: ssh-userauth
    debug1: got SSH2_MSG_SERVICE_ACCEPT
    debug1: Authentications that can continue: publickey,gssapi-with-
    mic,keyboard-interactive
    debug3: start over, passed a different list publickey,gssapi-with-
    mic,keyboard-interactive
    debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-
    interactive,password
    debug3: authmethod_lookup gssapi-with-mic
    debug3: remaining preferred: publickey,keyboard-interactive,password
    debug3: authmethod_is_enabled gssapi-with-mic
    debug1: Next authentication method: gssapi-with-mic
    debug1: Failed to acquire GSS-API credentials for any mechanisms (No
    credentials were supplied, or the credentials were unavailable or
    inaccessible
    Unknown code 0
    )
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/u1/abovill/.ssh/identity
    debug3: no such identity: /home/u1/abovill/.ssh/identity
    debug1: Trying private key: /home/u1/abovill/.ssh/id_rsa
    debug3: no such identity: /home/u1/abovill/.ssh/id_rsa
    debug1: Trying private key: /home/u1/abovill/.ssh/id_dsa
    debug3: no such identity: /home/u1/abovill/.ssh/id_dsa
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup keyboard-interactive
    debug3: remaining preferred: password
    debug3: authmethod_is_enabled keyboard-interactive
    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 25 padlen 7 extra_pad 64)
    debug2: input_userauth_info_req
    debug2: input_userauth_info_req: num_prompts 0
    debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
    debug1: Authentication succeeded (keyboard-interactive)
    debug1: channel 0: new [client-session]
    debug3: ssh_session2_open: channel_new: 0
    debug1: send channel open 0
    debug1: Entering interactive session.
    debug2: callback start
    debug1: ssh_session2_setup: id 0
    debug1: channel request 0: pty-req
    debug3: tty_make_modes: ospeed 38400
    debug3: tty_make_modes: ispeed 38400
    debug3: tty_make_modes: 1 3
    debug3: tty_make_modes: 2 28
    debug3: tty_make_modes: 3 127
    debug3: tty_make_modes: 4 21
    debug3: tty_make_modes: 5 4
    debug3: tty_make_modes: 6 0
    debug3: tty_make_modes: 7 0
    debug3: tty_make_modes: 8 17
    debug3: tty_make_modes: 9 19
    debug3: tty_make_modes: 10 26
    debug3: tty_make_modes: 11 25
    debug3: tty_make_modes: 12 18
    debug3: tty_make_modes: 13 23
    debug3: tty_make_modes: 14 22
    debug3: tty_make_modes: 16 0
    debug3: tty_make_modes: 18 15
    debug3: tty_make_modes: 30 0
    debug3: tty_make_modes: 31 0
    debug3: tty_make_modes: 32 0
    debug3: tty_make_modes: 33 0
    debug3: tty_make_modes: 34 0
    debug3: tty_make_modes: 35 0
    debug3: tty_make_modes: 36 1
    debug3: tty_make_modes: 37 0
    debug3: tty_make_modes: 38 1
    debug3: tty_make_modes: 39 0
    debug3: tty_make_modes: 40 0
    debug3: tty_make_modes: 41 0
    debug3: tty_make_modes: 50 1
    debug3: tty_make_modes: 51 1
    debug3: tty_make_modes: 52 0
    debug3: tty_make_modes: 53 1
    debug3: tty_make_modes: 54 1
    debug3: tty_make_modes: 55 1
    debug3: tty_make_modes: 56 0
    debug3: tty_make_modes: 57 0
    debug3: tty_make_modes: 58 0
    debug3: tty_make_modes: 59 1
    debug3: tty_make_modes: 60 1
    debug3: tty_make_modes: 61 1
    debug3: tty_make_modes: 62 0
    debug3: tty_make_modes: 70 1
    debug3: tty_make_modes: 71 0
    debug3: tty_make_modes: 72 1
    debug3: tty_make_modes: 73 0
    debug3: tty_make_modes: 74 0
    debug3: tty_make_modes: 75 0
    debug3: tty_make_modes: 90 1
    debug3: tty_make_modes: 91 1
    debug3: tty_make_modes: 92 0
    debug3: tty_make_modes: 93 0
    debug1: channel request 0: shell
    debug1: fd 3 setting TCP_NODELAY
    debug2: callback done
    debug1: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Last login: Wed Nov 8 13:19:48 2006 from mason.gmu.edu
    debug1: temporarily_use_uid: 1000/5000 (e=0/5000)
    debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
    debug1: restore_uid: 0/5000
    debug3: PAM: opening session
    debug1: PAM: reinitializing credentials
    debug1: permanently_set_uid: 1000/5000
    Environment:
    USER=andy
    LOGNAME=andy
    HOME=/home/andy
    PATH=/usr/bin:/bin:/usr/sbin:/sbin
    MAIL=/var/mail/andy
    SHELL=/bin/bash
    SSH_CLIENT=129.174.1.13 45696 2222
    SSH_CONNECTION=129.174.1.13 45696 192.168.183.2 2222
    SSH_TTY=/dev/pts/3
    TERM=xterm
    debug3: channel 0: close_fds r -1 w -1 e -1 c -1


    Thanks for any help on this!

  4. Re: pam_krb5 does not get credentials when using ssh



    Andrew Bovill wrote:
    > On Wed, 08 Nov 2006 06:06:34 +0000, Andrew Bovill wrote:
    >
    >
    >>pam_krb5 gives credentials (using a 'random' cache) just fine when loging
    >>in on the local machine. However, if I log in over ssh, it does not get
    >>the krb5 tickets, though it authenticates off kerberos just fine. I am
    >>appending my pam config for system authentication:

    >
    >
    > I forgot to mention, the sshd server I'm using is kerberized:
    > OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 with kerberos support.
    >


    On what OS?

    Which pam_krb5? There are a few different versions with different options.

    Something to keep in mind:

    * KerberosAuthentication yes, KerberosOrLocalPasswd yes and
    KerberosTicketCleanup yes all apply to password authentication,
    where sshd calls kerberos directly. (You may not want this.)

    * Keyboard interactive is handled by PAM, that can use Kerberos
    if pam_krb5 is successful. (Preffered method.)

    * GSSAPI authentication is using kerberos tickets, and sshd
    will call the pam session routines so as to handle delegated
    credentials, i.e. forwarded tickets.

    * Some sshd implementaitons will uss a different pam service name
    depending on the method used. I don't think OpenSSH-4.x does.

    So there are two seperate paths to consider, keyboard-interactive
    for passwords, and gssapi-with-mic for Kerberos ticket authenticaiton.

    With keyboard-interactive, privsep may get in the way. If your pam_krb5
    has a force type option, to store the tickets during pam_sm_authenticate,
    rather the pam_sm_setcreds. give that a try.

    With gssapi-with-mic, sshd store any delegated credentials (i.e. ssh_config
    or user had set GSSAPIDelegateCredentials yes) and set KRB5CCNAME
    in the pam_env, and call the pam_open_session. (This is where AFS could
    use these, but you are not using AFS.) In you case there is nothing
    to do.

    > --Andrew
    > ________________________________________________
    > 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


  5. Re: pam_krb5 does not get credentials when using ssh

    On Thu, 09 Nov 2006 09:30:33 -0600, Douglas E. Engert wrote:
    >
    > On what OS?

    Sorry, It's gentoo Linux (running 2.6.17)
    >
    > Which pam_krb5? There are a few different versions with different options.

    The version is listed as: 20030601-r1

    > Something to keep in mind:
    >
    > * KerberosAuthentication yes, KerberosOrLocalPasswd yes and
    > KerberosTicketCleanup yes all apply to password authentication,
    > where sshd calls kerberos directly. (You may not want this.)
    >


    I just tried both with the kerberos options turned on, and off, with the
    same results when I log in without any initial credentials: when I type
    klist, I get the following:
    andy@bloo ~ $ klist
    klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)

    now, the annoying thing is this: If I connect to my debian box, running
    pam_krb5 1.0-12, I get the following after logging in with no credentials:
    andy@svn:~$ klist
    Ticket cache: FILE:/tmp/krb5cc_1000_kFf7w3
    Default principal: andy@EEBLE.NET

    Valid starting Expires Service principal
    11/09/06 10:54:05 11/09/06 20:54:05 host/svn.eeble.net@EEBLE.NET
    renew until 11/09/06 20:54:06
    11/09/06 10:54:05 11/09/06 20:54:05 krbtgt/EEBLE.NET@EEBLE.NET
    renew until 11/09/06 20:54:06

    The pam.d/common-* files are using the same pam_krb5 options that are
    being used on my gentoo box, and the /etc/ssh/sshd_config file uses the
    same basic options (with regards to kerberos and gssapi)

    > * Keyboard interactive is handled by PAM, that can use Kerberos
    > if pam_krb5 is successful. (Preffered method.)
    >
    > * GSSAPI authentication is using kerberos tickets, and sshd
    > will call the pam session routines so as to handle delegated
    > credentials, i.e. forwarded tickets.
    >

    This works fine. If I have kerberos credentials, they will get used and I
    won't have to give my password.

    > * Some sshd implementaitons will uss a different pam service name
    > depending on the method used. I don't think OpenSSH-4.x does.
    >
    > So there are two seperate paths to consider, keyboard-interactive for
    > passwords, and gssapi-with-mic for Kerberos ticket authenticaiton.

    If I understand you correctly, I should be using password interactive if
    the user has no credentials, and gssapi-with-mic if the user does?
    (gssapi-with-mic seems to be working fine, for the most part)


    > With keyboard-interactive, privsep may get in the way. If your pam_krb5
    > has a force type option, to store the tickets during
    > pam_sm_authenticate, rather the pam_sm_setcreds. give that a try.


    I turned off privsep in sshd, was that what you meant? I didn't see any
    force option for the version of pam_krb5 that I am using...

    > With gssapi-with-mic, sshd store any delegated credentials (i.e.
    > ssh_config or user had set GSSAPIDelegateCredentials yes) and set
    > KRB5CCNAME in the pam_env, and call the pam_open_session. (This is where
    > AFS could use these, but you are not using AFS.) In you case there is
    > nothing to do.

    Judging by the name of the krb5 cache name after I log in over ssh, pam is
    not setting KRB5CCNAME when I log in over ssh. when I log in at the
    console, or I log in to my debian boxes, it sets the krb5 cache name to
    /tmp/krb5_UID_XXXXX

    Thanks for the help, I appreciate it.

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



  6. Re: pam_krb5 does not get credentials when using ssh

    "Andrew Bovill" wrote:
    > pam_krb5 gives credentials (using a 'random' cache) just fine when loging
    > in on the local machine. However, if I log in over ssh, it does not get
    > the krb5 tickets, though it authenticates off kerberos just fine.


    There is a problem with the way the pam API was designed and
    sshd's privilege separation feature. I don't remember the
    details, but IIRC pam_krb5 attaches private information to a
    handle, that isn't there when the handle is accessed from a
    different process.

  7. Re: pam_krb5 does not get credentials when using ssh

    Markus Schaaf writes:
    > "Andrew Bovill" wrote:


    >> pam_krb5 gives credentials (using a 'random' cache) just fine when
    >> loging in on the local machine. However, if I log in over ssh, it does
    >> not get the krb5 tickets, though it authenticates off kerberos just
    >> fine.


    > There is a problem with the way the pam API was designed and sshd's
    > privilege separation feature. I don't remember the details, but IIRC
    > pam_krb5 attaches private information to a handle, that isn't there when
    > the handle is accessed from a different process.


    If that's the problem, switching to a better Kerberos v5 PAM module, such
    as the one at:



    may fix the problem. Most current PAM modules try to work around this in
    various ways.

    --
    Russ Allbery (rra@stanford.edu)

  8. Re: pam_krb5 does not get credentials when using ssh

    Russ Allbery wrote:
    > Markus Schaaf writes:
    > > "Andrew Bovill" wrote:

    >
    > >> pam_krb5 gives credentials (using a 'random' cache) just fine when
    > >> loging in on the local machine. However, if I log in over ssh, it does
    > >> not get the krb5 tickets, though it authenticates off kerberos just
    > >> fine.

    >
    > > There is a problem with the way the pam API was designed and sshd's
    > > privilege separation feature. I don't remember the details, but IIRC
    > > pam_krb5 attaches private information to a handle, that isn't there when
    > > the handle is accessed from a different process.

    >
    > If that's the problem, switching to a better Kerberos v5 PAM module, such
    > as the one at:
    >
    >
    >
    > may fix the problem. Most current PAM modules try to work around this in
    > various ways.
    >
    > --
    > Russ Allbery (rra@stanford.edu)


    Thanks a lot to everyone that helped. It turns out that the version of
    pam_krb5 I was using, was broken (but listed as stable, joy) so I had
    to force gentoo to install another version, which fixed the problem
    instantly. Thanks again! It's so nice to not have to enter my password
    5 times when administering machines.
    --Andrew


+ Reply to Thread