DataStax Help Center

CQLSH login with Kerberos fails with "Unable to obtain password from user"


When using Kerberos authentication for DSE, if the hostname is not derived by DSE to match the configured service principal hostnames, then the login to cqlsh and other clients will fail


After validating the following:

  • listprincs shows all the correct relevant service principals
  • The user is able to kinit from the DSE node
  • The keytab has the correct permissions for the DSE user (usually cassandra)
  • The keytab has the correct service principals as configured in the KDC server
  • The dse.yaml has all the relevant correct Kerberos configuration

Using the --debug switch the following kind of error may be observed

$ cqlsh --debug 
Using CQL driver: <module 'cassandra' from '/usr/share/dse/cassandra/lib/'> 
Using connect timeout: 5 seconds 
Using 'utf-8' encoding 
Using DSEGSSAPIAuthProvider(service=cassandra, qops=auth) 
This will only be used if the server requests kerberos authentication 
Connection error: ('Unable to connect to any servers', {'': AuthenticationFailed('Failed to authenticate to Error from server: code=0000 [Server error] message="java.lang.RuntimeException: Unable to obtain password from user\n"',)})


Normally the dse.yaml will have the following configuration for the Kerberos service principals (where <REALM>is your required Kerberos realm)

  keytab: /etc/dse/dse.keytab
  service_principal: dse/_HOST@<REALM>
  http_principal: HTTP/_HOST@<REALM>
  qop: auth  

Note the _HOST placeholder above. This will normally be derived from a reverse DNS lookup of the broadcast ip address to give a fully qualified domain name (fqdn) of the node . So for example would have a service principal of dse/ however if the fqdn isn’t derived correctly then it could mean the service princpal passed up to the KDC server is wrong.


In such cases the dse.yaml can be configured with the fqdn instead of using the placeholder, for example:

  keytab: /etc/dse/dse.keytab
  service_principal: dse/
  http_principal: HTTP/
  qop: auth  


Ensure your service principals match the expected fqdn of the node. Typically on most Linux distros nslookup <ip address> will give you that.


Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Powered by Zendesk