Should I disable GSSAPIAuthentication in sshd_config when joining to a windows domain via SSSD

Latest response


Quick question as I can't find many results on the internet. I'm working on joining a test system to our windows domain via SSSD to utilize remote identity and authentication but i noticed the default sshd_config file has GSSAPIAuthentication=yes. This means i can ssh into a system joined to the domain without specifying creds if my client machine has a valid ticket. I'm confused because the man pages say this default value is No but even removing the sshd_config file and reinstall openssh-server, it changes it back to yes. Does anybody know if there are any dependencies within the system that would require this? I doubt it but could be wrong. I'm assuming that disabling this would only affect ssh client-side authenticating to the system? Thanks in advance.


Hello Christoper Lebron,

I don't think that the "GSSAPIAuthentication" is required in case of using SSSD. Mostly, GSS-API is used when authentication protocol is Kerberos. But SSSD can interact with Kerberos as well. I don't have much information to share regarding this. Lets see if any community members has to say anything about it.

All the best!

Hello Christopher, I have been working with Redhat and this setting with regard to Linux, but what I have learned is that the ssh_config file is the client-side setting, and sshd_config is the server side setting. I have be reading for security reasons that the setting should be set as "GSSAPIAuthentication no" in both the files, and your right, the default seems to be "yes" upon any installation.


There is nothing wrong in using GSSAPIAuthentication. It all depends on the IT Security policy in a specific organisation.

As Sadashiva said, GSSAPIAuthentiation relies on Kerberos. When GSSAPIAuthentication is enabled , SSH uses Kerberos ticket to authenticate the user.

Please note two conditions that can affect GSSAPI-based logins:

a) Entries similar to these must exist in /etc/hosts:   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

b) Valid DNS records for the server (including rDNS - reverse resource records).

At the base level, I "played" with six methods that RHEL supports (excluding biometrics for the moment):

• Password authentication: Client enters a password, encrypts it and uses it to authenticate itself to  server.

• Public key authentication: Each client uses a key pair to authenticate itself to server.

• Host based authentication: Similar to public key authentication, and client  should not only use correct key, but also must connect from correct host. Recommended to enable “Match” directive with Host Based Authentication.

• Keyboard authentication: Server will request client to present zero or more prompts and request  answers.

PAM → You can use Google Authenticator PAM Module to configure Two Factor Authentication
RSA SecureID
And others

• Challenge Response Authentication: used to configure keyboard authentication (RFC 4256).

And others

• GSSAPI Authentication: GSSAPI is an IETF standard for strong encrypted authentication (Kerberos).

In one of the places where I work, they enabled GSSAPIAuthentication and they exclusively rely on SSSD for authenticating users with remote Microsoft AD servers. It works very well.


Dusan Baljevic (amateur radio VK2COT)

@Dusan Baljevic

Could you put together a guide around GSSAPI configuration with Windows Active Directory?

It would be helpful if someone were to say they've been able to get it to work with RHEL9. At the moment, I haven't been able to locate a success story.

I had never heard of the requirement for reverse dns to be setup. I added that to my setup but still not working.


Hi Travis,

I replied to your other question in a separate discussion.

Let's see if we can sort out your RHEL 9 problem.


Dusan Baljevic (amateur radio VK2COT)