OpenSSH & LDAP: Key Auth, Locked & Idle User Policies

by Benjamin Cohen 54 views

Introduction

Hey guys! Let's dive into a super interesting topic: OpenSSH key authentication and how it plays with LDAP policies, especially when dealing with locked or idle users. If you're managing a system where most of your users are coming from an OpenLDAP server and logging in via SSH, this is definitely something you’ll want to wrap your head around. We'll break down how key-based authentication interacts with your LDAP password policies and what you need to consider to keep your system secure and user-friendly.

The Challenge: Key Authentication vs. LDAP Policies

So, here's the deal. You've got a bunch of users, some logging in with passwords and others using SSH keys. You've wisely set up password policies in LDAP to lock accounts after too many failed login attempts or after a period of inactivity. This is great for security! But what happens when users log in with keys? Do these policies still apply? This is a crucial question because key-based authentication bypasses the traditional password prompt, which means the usual checks against the password policy might not kick in. This can lead to a situation where a user's account is locked according to LDAP, but they can still log in using their SSH key. This effectively circumvents your security measures, which isn’t ideal.

We need to explore how OpenSSH interacts with LDAP in the context of key-based authentication. When a user attempts to log in using a key, the authentication process is different from when they use a password. With passwords, the system typically consults LDAP to verify the credentials and enforce password policies. However, key authentication relies on cryptographic keys, and the system checks if the provided key matches an authorized key stored on the server. This process, by default, doesn’t directly involve LDAP password policy checks. To properly address this challenge, we need to consider a few key areas:

  1. Understanding the Authentication Flow: Let's first break down the standard authentication flow for both password-based and key-based logins. This will help us pinpoint where the LDAP policies come into play and where they might be bypassed.
  2. Exploring OpenSSH Configuration: We'll then look at OpenSSH configuration options that can help us integrate LDAP policy checks into the key authentication process. There are certain settings and methods we can use to ensure that even key-based logins are subject to the same security rules as password-based logins.
  3. Implementing PAM (Pluggable Authentication Modules): PAM is a powerful tool that allows us to integrate various authentication methods and policies. We'll see how we can use PAM to ensure that LDAP policies are enforced regardless of the authentication method used.
  4. Considering Account Status and Idle Time: Finally, we need to think about how to handle locked accounts and idle users in the context of key-based authentication. This includes checking for account status and implementing mechanisms to disconnect idle sessions.

By addressing these areas, we can ensure that our OpenSSH setup properly respects LDAP policies, even when users are authenticating with keys. This will help us maintain a secure and consistent authentication system.

Understanding the Authentication Flow

Okay, let’s break down how authentication works, both with passwords and SSH keys. This will give us a clearer picture of where LDAP policies typically come into play and where things might get a little… complicated with key-based logins.

Password-Based Authentication

When a user logs in with a password, the process generally looks like this:

  1. User Enters Credentials: The user types their username and password into the SSH client.
  2. Connection to SSH Server: The client connects to the SSH server on the target machine.
  3. Password Verification: The SSH server receives the username and password. Here’s where things get interesting for us. The server typically uses the Pluggable Authentication Modules (PAM) framework to handle authentication.
  4. PAM and LDAP: PAM is configured to use LDAP as one of its authentication sources. This means PAM consults the LDAP server to verify the password.
  5. LDAP Policy Checks: The LDAP server checks the provided password against any configured policies. This includes checking for things like:
    • Incorrect password attempts: If the user has entered the wrong password too many times, the account might be locked.
    • Password age: If the password is too old, the user might be forced to change it.
    • Password complexity: The password might need to meet certain complexity requirements (e.g., minimum length, special characters).
    • Account status: The LDAP server checks if the account is active, locked, or disabled.
  6. Authentication Success/Failure: If the password is valid and the account is active, the LDAP server tells PAM that the authentication was successful. Otherwise, PAM reports a failure.
  7. SSH Session Established: If PAM reports success, the SSH server allows the user to log in and establishes an SSH session.

So, with password-based authentication, LDAP policies are front and center. The system actively checks the user's credentials and account status against the LDAP server before granting access.

Key-Based Authentication

Now, let's look at key-based authentication. This process is quite different:

  1. Key Exchange: The user’s SSH client and the SSH server perform a cryptographic key exchange. This involves the client proving that it has the private key corresponding to a public key stored on the server.
  2. Authorized Keys File: The server checks the ~/.ssh/authorized_keys file (or a system-wide equivalent) for the user. This file contains a list of public keys that are authorized to log in to the user's account.
  3. Key Match: The server compares the key presented by the client with the keys in the authorized_keys file. If there's a match, the server knows the client has the corresponding private key.
  4. Authentication Success: If the keys match, the SSH server authenticates the user.
  5. SSH Session Established: The SSH server establishes an SSH session without ever prompting for a password.

Notice anything missing? That’s right, the standard key-based authentication process doesn't directly involve LDAP. The server is essentially saying,