9:15 AM
1
Q: SSH with Kerberos authentication

michele_ubI am encountering the following problem: I am trying to connect from a client VM to a server VM using SSH with Kerberos authentication, but SSH still asking me for password. Obviously, I modified the /etc/ssh/sshd_config file, on server side, to enable: GSSAPIAuthentication yes and GSSAPICleanupC...

 
looks like you forgot to get a ticket as user michele. Try running "kinit" and then ssh again.
 
I have just tried, but ssh still asking for password. micheleclient@client:~$ sudo kinit michele [sudo] password di micheleclient: Password for michele@SERVER.COM: micheleclient@client:~$ sudo klist -ef Ticket cache: FILE:/tmp/krb5cc_1002 Default principal: michele@SERVER.COM Valid starting Expires Service principal 07/05/2018 09:43:48 08/05/2018 09:43:48 krbtgt/SERVER.COM@SERVER.COM Flags: FPI, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 micheleclient@client:~$ ssh michele@server.com michele@server's password:
I also made same changes: adding the row default_ccache_name = /tmp/krb5cc_1002 in the krb5.conf file to force the access to that cache, and verified the permission on that file: micheleclient@client:/tmp$ ls -l krb5cc_1002 -rw------- 1 root root 695 mag 7 09:43 krb5cc_1002 and looking at ssh debug I get: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available: Credentials cache permissions incorrect (filename: /tmp/krb5cc_1002) before askin for password. Something went wrong with credentials.
 
You should not use sudo with kinit, just kinit. It should be owned by your own user.
 
Well, I used sudo just because the user registered in the SERVER.COM (my realm) realm is michele (michele@SERVER.COM) and not micheleclient. By typing su michele, and using kinit (without sudo) I get michele@client:~$ kinit Password for michele@SERVER.COM: kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1002) while getting initial credentials
 
of course, because the file is owned by root now. Remove it and try again please.
 
9:15 AM
you mean, remove the /tmp/krb5cc_1002 file stored on the client machine?
Dear Sebastian, I am getting crazy. I have been trying for many days. Sorry if I text you...
I removed the krb5cc_1002 file in the /tmp directory and I got the ticket!
I have just typed: ssh -v server.com (server.com is the hostname of server machine and the IP address was added in the /etc/host file), but it still asking me for password and debug gets me: debug1: Delegating credentials
debug1: Delegating credentials
debug1: Unspecified GSS failure. Minor code may provide more information
The ticket isn't for us
so, is able to delegate credentials...
 
9:45 AM
now that's a different errir
 
yes but I don't understand why
 
could be related to cache file stored on the server machine?
 
I don't think so
what does klist show on the client?
 
for the same user I mean, because I have a user called michele on the server machine and a principal called michele@SERVER.COM
I try...
michele@client:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1002
Default principal: michele@SERVER.COM

Valid starting Expires Service principal
07/05/2018 11:18:48 08/05/2018 11:18:48 krbtgt/SERVER.COM@SERVER.COM
07/05/2018 11:20:05 08/05/2018 11:18:48 host/server.com@SERVER.COM
 
9:48 AM
that looks good
 
yes
really good because it can see the ssh service host/server.com
the principal I created for the SSH Kerberized service
 
I am sorry I have to leave for an hour or so, I will come back after that
 
ok ok. don't worry and thanks a lot
if you want or prefer we could text in another chat
 
 
1 hour later…
11:07 AM
ok
what is the exact ssh command line you are using?
what is the exact DNS name of server.com?
and what is the output of "sudo ktutil list | grep server.com" on the server?
 
well...I used differents way...1) ssh -vv server.com (if am michele user in the client machine) or just ssh server.com
the hostname is: server
and IP address is: 192.168.56.4
both listed in the /etc/host file
 
the point is
the iP doesn't matter :)
only the name
 
it needs to be the same in krb5.keytab and on the command line
so if you added the server to krb5.keytab as "server.com", you have to use "ssh server.com"
 
I show you the output of klist -k
just a moment please
root@server:/tmp# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 host/server.com@SERVER.COM
4 host/server.com@SERVER.COM
2 host/server@SERVER.COM
2 host/server@SERVER.COM
 
11:15 AM
looks good
 
great
now...I show yout that command
few seconds
it is taking too much time the command sudo ktutil list | grep server.com
on the server machine
 
ah, you use mit krb5, right? then it doesnt work like this...
(I use heimdal)
sorry, I don't know the equivalent command in MIT krb
 
And I want to say you that I found the following on google: The ticket isn't for us

Ticket/authenticator don't match

Cause: There was a mismatch between the ticket and authenticator. The principal name in the request might not have matched the service principal's name, because the ticket was being sent with an FQDN name of the principal while the service expected non-FQDN, or vice versa.

Solution: If you get this error when you are running applications other than kprop, investigate whether the server's keytab file is correct.
ah ok ok I use MIT implementation
 
try the following: GSSAPIStrictAcceptorCheck=no in sshd_config on server
 
mmm
ok
 
11:19 AM
if that makes it work, than it's liokely a hostname or DNS issue
 
only on the server side?
 
ja
yes
:)
 
shoud I restart ssh service after? ssh service restart?
 
ok
wow
you are a genius
damn
great
 
11:22 AM
thanks :)
 
IT WORKS
wait
I re-type to be sure
ahahahah
can I add you on Facebook?
 
I don't have facebook
I'll write up an answer about that later, have to leave again for a bit
(will check back here later)
 
/tmp$ ssh -vv server.com
OpenSSH_7.5p1 Ubuntu-10ubuntu0.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for server.com
debug1: /etc/ssh/ssh_config line 33: Applying options for *
debug2: resolving "server" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to server [192.168.56.4] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/michele/.ssh/id_rsa type -1
that's all
what kind of social account you have? just for further help, but I don't want to give you troubles
THANK YOU SO MUCH FRIEND
 
 
1 hour later…
12:49 PM
I don't use social media :)
 
 
1 hour later…
1:56 PM
ah ok ok. Thanks a lot guy!
 
2:49 PM
did you get your dns issue sorted or will you stick with "GSSAPIStrictAcceptorCheck no"?