Kerberized SSH Failed

Question

I want to authenticate ssh login with Kerberos, however fail. The following is a snippet of ssh debug information with the command ssh -vvv localhost.

debug3: Wrote 80 bytes for a total of 1125
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
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
debug3: Trying to reverse map address ::1.
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: Wrote 96 bytes for a total of 1221
debug1: Delegating credentials
debug3: Wrote 1408 bytes for a total of 2629
debug1: Delegating credentials
debug3: Wrote 64 bytes for a total of 2693
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: Wrote 96 bytes for a total of 2789
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: Wrote 96 bytes for a total of 2885
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: Wrote 96 bytes for a total of 2981
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
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

Here is some server debugging information

debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 4220
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 74:74
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 784 bytes for a total of 805
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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,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-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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug3: mm_request_send entering: type 78
debug3: mm_request_receive_expect entering: type 79
debug3: mm_request_receive entering
debug3: monitor_read: checking request 78
debug3: mm_request_send entering: type 79
debug3: mm_request_receive entering
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug3: mm_request_send entering: type 78
debug3: mm_request_receive_expect entering: type 79
debug3: mm_request_receive entering
debug3: monitor_read: checking request 78
debug3: mm_request_send entering: type 79
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 1024 8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug3: Wrote 152 bytes for a total of 957
debug2: dh_gen_key: priv key bits set: 121/256
debug2: bits set: 513/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 520/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 5
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 6
debug3: mm_request_receive entering
debug3: mm_request_receive entering
debug3: monitor_read: checking request 5
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x7f2b3128ca10(271)
debug3: mm_request_send entering: type 6
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
debug3: Wrote 720 bytes for a total of 1677
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug2: monitor_read: 5 used once, disabling now
debug3: mm_request_receive entering
debug3: Wrote 48 bytes for a total of 1725
debug1: userauth-request for user username service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 7
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 8
debug3: mm_request_receive entering
debug3: monitor_read: checking request 7
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address ::1.
debug2: parse_server_config: config reprocess config len 587
debug3: auth_shadow_acctexpired: today 15818 sp_expire -1 days left -15819
debug3: account expiration disabled
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 8
debug2: input_userauth_request: setting up authctxt for username
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug3: mm_inform_authrole entering
debug3: mm_request_send entering: type 4
debug2: input_userauth_request: try method none
debug3: Wrote 80 bytes for a total of 1805
debug2: monitor_read: 7 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_authrole: role=
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: userauth-request for user username service ssh-connection method gssapi-with-mic
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method gssapi-with-mic
debug3: mm_request_send entering: type 38
debug3: mm_request_receive_expect entering: type 39
debug3: mm_request_receive entering
debug3: monitor_read: checking request 38
debug3: mm_request_send entering: type 39
Postponed gssapi-with-mic for username from ::1 port 48263 ssh2
debug3: Wrote 48 bytes for a total of 1853
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 40
debug3: mm_request_receive_expect entering: type 41
debug3: mm_request_receive entering
debug3: monitor_read: checking request 40
debug1: Received some client credentials
debug3: mm_request_send entering: type 41
debug3: mm_request_receive entering
debug3: Wrote 192 bytes for a total of 2045
debug3: mm_request_send entering: type 44
debug3: mm_request_receive_expect entering: type 45
debug3: mm_request_receive entering
debug3: monitor_read: checking request 44
debug3: mm_request_send entering: type 45
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 42
debug3: mm_request_receive_expect entering: type 43
debug3: monitor_read: checking request 42
debug3: mm_request_receive entering
debug3: mm_answer_gss_userok: sending result 0
debug3: mm_request_send entering: type 43
Failed gssapi-with-mic for username from ::1 port 48263 ssh2
debug3: mm_ssh_gssapi_userok: user not authenticated
debug3: Wrote 80 bytes for a total of 2125
debug3: mm_request_receive entering
debug1: userauth-request for user username service ssh-connection method gssapi-with-mic
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
debug3: Wrote 80 bytes for a total of 2205
debug1: userauth-request for user username service ssh-connection method gssapi-with-mic
debug1: attempt 3 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
debug3: Wrote 80 bytes for a total of 2285
debug1: userauth-request for user username service ssh-connection method gssapi-with-mic
debug1: attempt 4 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
debug3: Wrote 80 bytes for a total of 2365
debug1: userauth-request for user username service ssh-connection method publickey
debug1: attempt 5 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 21
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 22
debug3: mm_request_receive entering
debug3: monitor_read: checking request 21
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x7f2b312988d0
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file /home/username/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file /home/username/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for username from ::1 port 48263 ssh2
debug3: mm_answer_keyallowed: key 0x7f2b312988d0 is not allowed
debug3: mm_request_send entering: type 22
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 80 bytes for a total of 2445

Tail from Kerberos log:

Apr 23 21:35:40 hostname krb5kdc[25099](info): TGS_REQ (1 etypes {18}) 127.0.0.1: ISSUE: authtime 1366693210, etypes {rep=18 tkt=18 ses=18}, username/localhost@LOCALHOST for krbtgt/LOCALHOST@LOCALHOST

From the debug information, it seems client fails for the reason that message is written partially. As to the server side debugging information, I didn't get too much useful information limited by my knowledge. What may cause this problem?

(I have Kerberos deployed and can get krbtgt ticket correctly. Also, I've add credential of host/localhost@LOCALHOST principal into /etc/krb5.keytab. My default realm is LOCALHOST. sshd principal host/localhost@LOCALHOST my user principal username/localhost@LOCALHOST. Any other things to check? My platform is CentOS 6.4 x86_64 final release. Both sshd and kdc are on the same machine, i.e. localhost and I try to login from localhost to localhost)

Thank you and best regards!

UPDATES:

sshd_config related to GSS and Kerberos:

# Kerberos options
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange yes

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no
#UsePAM yes

The log from the server, with `LogLevel DEBUG` is usually more helpful — dawud, Apr 23 '13 at 13:04
@dawud Update my question, could you please give me some hints? Thank you very much :). — Summer_More_More_Tea, Apr 23 '13 at 13:41
Please provide your sshd_config, specifically lines related to Kerberos, GSSAPI — dawud, Apr 23 '13 at 14:37
Please post your OS name and version, as well as whether you are using modified PAM config files or/and `sssd` — dawud, Apr 23 '13 at 18:20
@dawud I'm on CentOS 6.4 x86_64 final release and use default settings for PAM and sssd. (in fact, I have little knowledge about these two stuff :p). Thank you for your attention. — Summer_More_More_Tea, Apr 24 '13 at 01:26
Unless the hostname is also "localhost" (as returned/set by hostname(1)), you'll need GSSAPIStrictAcceptorCheck=no. With the default setting ("yes"), the server accepts only tickets for the principal host/@REALM. With "no," it accepts any ticket it can validate with any key in its keytab. — Richard E. Silverman, Feb 28 '14 at 06:13
Can you re-run your command with KRB5_TRACE env var? Example: `KRB5_TRACE=/dev/stdout ssh -vvv localhost` You will see a bunch of debug into from Kerberos during GSSAPI negotiation... just after: `debug1: Next authentication method: gssapi-with-mic` — kevinarpe, Apr 06 '22 at 14:19

score 2 · Answer 1 · answered Dec 12 '14 at 22:17

It's quite old question, but someone might find it help full.

First of all: change sshd_config and use default option: UsePAM yes.

Logging on Centos/RedHat is through PAM to SSSD, and than Kerberos itself. The same is with SSH, it first looks on PAM config, and contact SSSD, than Kerberos.
Because of Kerberos verifing domain, I would recommend using external interface rather than loopback. If you do so, make sure that IP match your domain in /etc/hosts and your hostname is set (hostname localhost.localdomain and set it in /etc/sysconfig/network, key option HOSTNAME)
You can configure PAM and SSSD with command like this:

authconfig --update --enablelocauthorize --enablekrb5 --krb5realm LOCALHOST --krb5kdc localhost:88 --krb5adminserver localhost:749

SSSD config should contain:

krb5_realm = LOCALHOST
krb5_server = localhost:88 
auth_provider = krb5

kerberos krb5.conf:

[realms]
 LOCALHOST = {
 kdc = localhost:88
 master_kdc = localhost:88
 admin_server = localhost:749
 default_domain = localhost
 }

You can check as well check what Kerberos has to say while connecting with ssh. Belows works only with MIT Kerberos. To enable DEBUG on Kerberos use connection string like this:

[user@localhost]$ KRB5_TRACE=/dev/stdout ssh -vvv localhost

Setting debug on SSHD might help as well. you have to shut down working instance, and than for one connection only, run sshd with debug /usr/sbin/sshd -d -d -d . Notice that this will cause sshd to stop after client disconnect

using pam to authenticate against kerberos is different than using gssapi to authenticate against kerberos. pam requires you to use a password. — hildred, Oct 08 '18 at 00:40

Kerberized SSH Failed

1 Answers1