According to my understanding of Kerberos, a client is supposed to only enter its password once for obtaining the TGT from the Kerberos server and the authentication against the web services (f.e. SSH, Apache, SMB ...) is only done through the service ticket obtained from the Kerberos server.

In my current setup (check here for details), the client is being prompted for its Kerberos (!) password when authenticating to SSH. This happens after the client has already obtained a TGT from the Kerberos server.

To me, this behaviour seems quite odd since the whole idea about Kerberos seems to be that the authentication to a web service is done through tickets instead of passwords. But my colleague is convinced that this behaviour is expected and that the advantage of Kerberos is that the password never leaves the client. It's only used to validate the service ticket on the client's machine.

Can anyone clarify whether or not it is expected behaviour to be prompted for a password when authenticating to SSH via MIT Kerberos?

  • Please, post the debug log from your connection. There are different ways how the kerberos can be used in in authenticating over SSH.
    – Jakuje
    Jun 17, 2017 at 6:29
  • @Jakuje, my referenced question shows some verbose SSH output of my connection. I also added the logs I captured on the SSH daemon while connecting.
    – arne.z
    Jun 17, 2017 at 12:34

1 Answer 1


The simplest answer is probably not.

From looking at your current setup you are trying to use GSSAPIAuthentication. If your kerberos environment is properly set up then it should not be required to enter a password again after initially requesting your TGT. with this properly received it is only the TGT that is required to request the service ticket.

Some things to look out for are the following:

  • Things are simpler if you follow the convention of keeping your realm name in UPPERCASE.
  • Make sure all SPNs in your KDC match the FQDNs of the hosts you are authenticating to.
  • Make sure all hosts are actually aware of their FQDN. This can be achieved by editing /etc/hostname, /etc/hosts may also be useful.
  • It also looks like you are receiving brute force attempts against your ssh daemon as the user root, this can be helped by installing something like fail2ban. Failing this, you can run an instance of sshd in the foreground, on a non standard port, with extra debugging output using this command sudo /usr/sbin/sshd -p 9001 -D -dd. This will give you cleaner logs.
  • Thank you for your elaborate answer. Good to know that this is not how it's supposed to work. I'll see how I can fix it.
    – arne.z
    Jun 19, 2017 at 20:15
  • No worries! Good luck with your kerberos set up. I set up a similar kerberos environment recently and had a lot of headaches. If I have time I will try to post a better response to your other question.
    – rlf
    Jun 19, 2017 at 20:28
  • That's so sweet of you!
    – arne.z
    Jun 19, 2017 at 20:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .