pam_krb5 does not get credentials when using ssh

Printable View

10-02-2007, 02:16 PM
unix

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
10-02-2007, 02:16 PM
unix

Re: pam_krb5 does not get credentials when using ssh

On Wed, 08 Nov 2006 06:06:34 +0000, Andrew Bovill wrote:
[color=blue]
> 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:[/color]

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
10-02-2007, 02:16 PM
unix

Re: pam_krb5 does not get credentials when using ssh

Andrew Bovill <abovill@gmail.com> wrote in
news:pan.2006.11.08.06.06.32.53163@gmail.com:
[color=blue]
> 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
>[/color]

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-
[email]cbc@lysator.liu.se[/email],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-
[email]cbc@lysator.liu.se[/email],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
[email]ripemd160@openssh.com[/email],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
[email]ripemd160@openssh.com[/email],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 [email]andy@eeble.net[/email]
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-
[email]cbc@lysator.liu.se[/email],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-
[email]cbc@lysator.liu.se[/email],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
[email]ripemd160@openssh.com[/email],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
[email]ripemd160@openssh.com[/email],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!
10-02-2007, 02:17 PM
unix

Re: pam_krb5 does not get credentials when using ssh

Andrew Bovill wrote:[color=blue]
> On Wed, 08 Nov 2006 06:06:34 +0000, Andrew Bovill wrote:
>
>[color=green]
>>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:[/color]
>
>
> 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.
>[/color]

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.
[color=blue]
> --Andrew
> ________________________________________________
> Kerberos mailing list [email]Kerberos@mit.edu[/email]
> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>
>[/color]

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
10-02-2007, 02:17 PM
unix

Re: pam_krb5 does not get credentials when using ssh

On Thu, 09 Nov 2006 09:30:33 -0600, Douglas E. Engert wrote:[color=blue]
>
> On what OS?[/color]
Sorry, It's gentoo Linux (running 2.6.17)[color=blue]
>
> Which pam_krb5? There are a few different versions with different options.[/color]
The version is listed as: 20030601-r1
[color=blue]
> 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.)
>[/color]

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: [email]andy@EEBLE.NET[/email]

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)
[color=blue]
> * 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.
>[/color]
This works fine. If I have kerberos credentials, they will get used and I
won't have to give my password.
[color=blue]
> * 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.[/color]
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)

[color=blue]
> 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.[/color]

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...
[color=blue]
> 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.[/color]
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.
[color=blue][color=green]
>> --Andrew
>> ________________________________________________ Kerberos mailing list
>> [email]Kerberos@mit.edu[/email]
>> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>>
>>[/color][/color]
10-02-2007, 02:17 PM
unix

Re: pam_krb5 does not get credentials when using ssh

"Andrew Bovill" <abovill@gmail.com> wrote:[color=blue]
> 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.[/color]

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.
10-02-2007, 02:17 PM
unix

Re: pam_krb5 does not get credentials when using ssh

Markus Schaaf <markus@sags-per-mail.de> writes:[color=blue]
> "Andrew Bovill" <abovill@gmail.com> wrote:[/color]
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> 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.[/color]

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

<http://www.eyrie.org/~eagle/software/pam-krb5/>

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

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
10-02-2007, 02:17 PM
unix

Re: pam_krb5 does not get credentials when using ssh

Russ Allbery wrote:[color=blue]
> Markus Schaaf <markus@sags-per-mail.de> writes:[color=green]
> > "Andrew Bovill" <abovill@gmail.com> wrote:[/color]
>[color=green][color=darkred]
> >> 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.[/color][/color]
>[color=green]
> > 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.[/color]
>
> If that's the problem, switching to a better Kerberos v5 PAM module, such
> as the one at:
>
> <http://www.eyrie.org/~eagle/software/pam-krb5/>
>
> may fix the problem. Most current PAM modules try to work around this in
> various ways.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>[/color]

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