SSH

Enable PAM for SSH

For your Active Directory account to work with SSH:

• Enable UsePAM in sshd_config
• Link sshd application to the PAM libraries

To configure SSH:

1. Determine which sshd is running by executing the following command:

bash-3.2# ps -ef | grep sshd
    root  8199     1  0  Feb  6  ?         0:00 /opt/ssh/sbin/sshd
    root  2987  8199  0  Mar  3  ?         0:04 sshd: root@notty
    root 24864  8199  0 12:16:25 ?         0:00 sshd: root@pts/0
    root  2998  8199  0  Mar  3  ?         0:05 sshd: root@notty
    root 24882 24880  0 12:16:54 pts/0     0:00 grep sshd

2. Either use lsof to find out which configuration file it is reading or start it up with debugging to figure out the default path.

✅

Example

username@computer:~$ /usr/sbin/sshd -dd -t
   debug2: load_server_config: filename /etc/ssh/sshd_config
   debug2: load_server_config: done config len = 664
   debug2: parse_server_config: config /etc/ssh/sshd_config len 664
   debug1: sshd version OpenSSH_5.1p1 Debian-3ubuntu1
   Could not load host key: /etc/ssh/ssh_host_rsa_key
   Could not load host key: /etc/ssh/ssh_host_dsa_key

3. Verify that UsePAM is enabled in the config file. As a best practice, make a backup copy of the configuration file before you change it.
4. Run ldd on sshd to make sure it links with libpam.

Configure GSSAPI for SSH

Logging onto a system with keys does not provide that system with the means of getting a PAC from the domain controller. Without a PAC there is no group membership information for the user. Automated Kerberos ticket renewal will also be unavailable. So, when the ssh login hits the login restrictions in the account phase as it tests for the group memberships, it will not find the user's group information, causing an ssh error like this:

Not in an Allowed Group!

A workaround is to have each user log in once with a password. Subsequent logins with keys should work until the AD cache is flushed, after which the user will have to log in again.

Check the configuration of SSH for SSO

Although AD Bridge automatically configures OpenSSH to support SSO through Kerberos using GSSAPI, it is worthwhile to review how AD Bridge does. Since you might need to configure or troubleshoot other applications for SSO, understanding the process will make it easier to apply the technique to other applications.

ℹ️

Note

Not all versions of OpenSSH support Kerberos. Versions older than 4.2p1 might not work or might work improperly.

SSH service principal name

The first thing that needs to be considered is the Kerberos service principal name (SPN) used by ssh and sshd. The SPN is a string that identifies the service for which an authentication ticket is to be generated. In the case of ssh, the SPN has the form:

host/<server name>@<REALMNAME>

For example, when a user uses ssh to connect to a computer named fozzie.mycorp.com, the ssh program requests a service ticket for the SPN:

host/[email protected]

The Kerberos realm is the computer's domain name in uppercase letters.

System keytab generation

In order for Microsoft Active Directory to generate a Kerberos ticket for this SPN, a service account must exist for it. Additionally, a keytab must be created for the service account and placed on the sshd server. AD Bridge completely automates this operation. When a Linux or Unix computer is joined to AD, a machine account is created for the computer. If the computer is called fozzie, a machine account called fozzie$ is created in AD. AD Bridge then automatically creates a keytab for the SPN and places it in the standard system location (typically, /etc/krb5.keytab).

User keytab generation

When the user runs the ssh program and OpenSSH determines that it will use Kerberos authentication, it will need to access a keytab for the user so that it can obtain a service ticket for the service or computer to which it is trying to connect. This keytab must be created using the user's account name and password. Manually, this can be performed by using the kinit utility. AD Bridge, however, does it automatically when the user logs on the computer. On most systems, the user keytab is placed in the /tmp directory and named krb5cc_UID where UID is the numeric user ID assigned by the system.

Configure OpenSSH

AD Bridge automatically configures OpenSSH at both the client and server computer. On the client, the ssh_config file (typically in /etc/ssh/ssh_config) is modified. On the server, ssh_config (typically in /etc/ssh/ssh_config) is modified. AD Bridge adds the following lines of code to the right files if they are not already present and if they are required by the system's version of sshd:

In the server, the following lines must be present in sshd_config. if you are troubleshooting, make sure these lines are there:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

On the client, the following line must be present in ssh_config:

GSSAPIAuthentication yes

On the client, GSSAPIDelegateCredentials yes is an optional setting that instructs the ssh client to delegate the krb5 TGT to the destination machine when SSH single sign-on is used.

In addition, if any of the following options are valid for the system's version of sshd, they are required and configured by AD Bridge:

ChallengeResponseAuthentication yes
UsePAM yes
PAMAuthenticationViaKBDInt yes
KbdInteractiveAuthentication yes

Setting these options to yes instructs ssh to use the kbdinteractive ssh authentication mechanism and allows that mechanism to use PAM, settings that are required for AD Bridge to function properly.

ℹ️

Note

For more information, see the man pages for ssh, sshd, and the comments in the ssh and sshd configuration files.

Test SSO

With OpenSSH properly configured, demonstrating SSO support is simple: Log on a Linux or Unix machine running AD Bridge by using your Active Directory credentials and then use ssh to connect to another machine that is also running AD Bridge. OpenSSH should establish a connection without prompting for a username or password.