1

I am working on getting SSH to accept AD credentials. Server details

  • CentOS 8
  • Server is successfully joined to the domain
  • Ran realm discover which returned proper information regarding our AD environment
  • realm permit run to permit specific users
  • SSH config file has been slightly modified. It mainly only blocks root logins.
  • SSH to the server using a local user account works.
  • User looking is possible using id someuser. I do not need to append upn suffix (@ad.sample.com).

Behavior

  • When signing in via SSH it prompts for user name (provided AD user name), then password (provide AD user password), and after providing the password the SSH session immediately terminates. I can see the request coming in via the /var/log/secure log and I can see that the credentials are being accepted. As soon as it passes authentication though the session is immediately closed. I tested using the wrong credentials for the user and can see this being reported in the secure log as all on the terminal itself.
  • I also tested trying to sign in via the actual server console, it initially appears to let me in, then immediately boots me back to login.
  • Interesting thing from the SSH debug is that the MOTD is visible.
  • When a new user attempts to sign in via SSH their home directory gets created.

Part of the output from SSH debug

[email protected]'s password:
debug3: packet_send2: adding 48 (len 72 padlen 8 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to x.x.x.x ([x.x.x.x]:xx).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting 
debug1: Entering interactive session.
debug1: client_input_global_request: rtype  want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env HOSTNAME
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env HISTSIZE
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Tue Jun  9 some date from x.x.x.x
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype  reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Connection to x.x.x.x closed.
Transferred: sent 2824, received 2420 bytes, in 0.1 seconds
Bytes per second: sent 24722.5, received 21185.7
debug1: Exit status 1

Our sssd.conf

[sssd]
domains = ad.sample.com
config_file_version = 2
services = nss, pam

[domain/ad.sample.com]
ad_domain = ad.sample.com
krb5_realm = AD.SAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
#use_fully_qualified_names = True
use_fully_qualified_names = False
#fallback_homedir = /home/%u@%d
fallback_homedir = /home/%u
access_provider = simple
simple_allow_users = someuser

I have checked several posts/blogs about setting this up and I don't think I've missed anything. I should mentioned that I have tried adding SSH to the services section in the sssd.conf file. It didn't make any difference.

Does anyone know what else I can check? Or what might be wrong?

7
  • Guess: Something executing in the system's or user's profile or similar startup scripts fail. If the MOTD is visible, look for the startup script that displays the MOTD; then you get at least this far.
    – dirkt
    Commented Jun 10, 2020 at 3:37
  • Would this sort of issue generate an error anywhere? Or do I just need to start commenting stuff out? I've honestly never really played around with these scripts.
    – bourne
    Commented Jun 10, 2020 at 3:55
  • 1
    Do they have a valid shell and home directory?
    – Jeff Schaller
    Commented Jun 10, 2020 at 10:26
  • The test user got a valid home directory. I can see it under under /home/ after they first attempted to sign in via SSH. I am unsure about the shell though. In the SSSD config file it has a setting for default_shell = /bin/bash.
    – bourne
    Commented Jun 10, 2020 at 11:16
  • Any other suggestions? I still have had no luck :(
    – bourne
    Commented Jun 12, 2020 at 0:50

2 Answers 2

0

Another thing to check is your access.conf file. Some of the behavior you describe can be done with settings to allow local accounts but deny others until valid group or users are set up.

1
  • I checked the /etc/security/access.conf config file and there is nothing currently configured there.
    – bourne
    Commented Jun 12, 2020 at 0:32
0

I was able to finally figure this issue out. There was one main issue:

  • My SSSD config was missing values to define the users shell

I was initially alerted to this issue by the following post: Highlight of error in SSH debug

Specifically, there was the following line the SSH debug that was indicating the problem

client_input_channel_req: channel 0 rtype exit-status reply 0

According to this link this shows that a shell cannot be selected for the user.

I checked our AD and the attribute for loginShell is populated, but the system doesn't appear to accept this. I added the following lines to my /etc/sssd/sssd.conf file

override_shell = /bin/bash
shell_fallback = /bin/bash

Once I added these, I was able to successfully login using SSH.

I then ran into another problem there the users home directory was not getting created. There is an AD attribute that can control this called unixHomeDirectory. We don't populate this for all users so I added an override for the home directory in the SSSD config as well.

override_homedir = /home/%u

The final config for SSSD looks like this:

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
ad_domain = example.com
krb5_realm = example.com
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
override_shell = /bin/bash
shell_fallback = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
override_homedir = /home/%u
access_provider = simple
simple_allow_users = someuser

You must log in to answer this question.

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