[TLDR: jump to The Table](#the-table)

## The Problem

The interplay between `sshd` and `PAM` is a bit confusing and can behave counterintuitively in some situations.
I also find it hard to remember because I very rarely need to know exactly how it works.

There is [one explanation of it](https://arlimus.github.io/articles/usepam/) that I have bookmarked but upon rereading it I find the phrasing to be ambiguous and in some cases it’s not clear to me which meaning of e.g. "locked account" is really meant.

NB: this blog post is _exclusively_ about the interplay of `sshd` and `PAM` and the differences in behaviour related to `sshd`’s `UsePAM` setting. No other aspects are taken into account, so a user may still be unable to log in even when login should be allowed according to the information given here e.g. when the user has no valid shell configured!

We will only be looking at the factors relevant for "locking" an account or a password:

* account expiry in `shadow`
* `UsePAM` setting in `sshd`
* content of password field in `shadow`


## The Simple Parts

### Expired Accounts are Locked

An expired account (`usermod -e 1 USER`) is never allowed to login, in any scenario, using any method (key vs password, etc.).

This is what `usermod(8)` refers to in the description of `--lock` with:

> Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.

Since this is a clearcut case for any combination, it will not be listed in the table to keep the table simple.


### Password Authentication

In short: is always possible when the password field in shadow contains a valid value, so this will also not be listed in the table.

#### Valid Password Field Content

If the password field in `shadow` contains a valid value, login using either password or key is allowed, regardless of the `UsePAM` setting. Other means may still disallow login, like `AuthenticationMethods`, `PubkeyAuthentication`, `KbdInteractiveAuthentication`, `PermitRootLogin`, etc.


#### Invalid Password Field Content

If the password field in `shadow` contains an invalid value, login using password is always disallowed, regardless of the `UsePAM` setting and whether it’s invalid because of a leading '!'. Neither with nor without PAM can this value be used to validate the given password.


## The Table

This table shows whether login is possible for combinations of "password field content" and the value of the `UsePAM` setting, e.g. with keys:

<table>
    <thead>
        <tr>
            <th>Password Field Content</th>
            <th><code>UsePAM</code></th>
            <th>Passwordless Login</th>
            <th>Reasoning</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td rowspan=2>starts with '!'</td>
            <td><code>Yes</code></td>
            <td>✅ Allowed</td>
            <td>for PAM only the password is locked, not the account</td>
        </tr>
        <tr>
            <td class=hide></td> <!-- needed for the borders to display properly because of the rowspan -->
            <td><code>No</code></td>
            <td>❌ Denied</td>
            <td>for SSH the account is locked, not just the password</td>
        </tr>
        <tr>
            <td>otherwise invalid</td>
            <td><code>Yes/No</code></td>
            <td>✅ Allowed</td>
            <td>to both PAM and SSH this has no special meaning</td>
        </tr>
    </tbody>
</table>

## Summary

The takeaways from all of this are:

* to lock an account, expire it with `usermod -e 1 henk`
* to lock a password, i.e. prevent the user from logging in using their password, make the password hash in `/etc/shadow` invalid, e.g. by changing it to '\*' or prefix it with '\*' manually
* `usermod -L henk` will prefix the password hash with '!' which will
  * lock _the account_ (i.e. not just the password!) for SSH _without_ PAM
  * lock _the password_ (i.e. not the whole account!) for SSH _with_ PAM