On 2025/06/11 12:46, Ratnasamy, Fritz via slurm-users wrote:
We wanted to block users from ssh to a node where there are no jobs running however it looks like users are able to do so. We have installed the slurm_pam_adopt_module and set up the slurm.conf accordingly (the same way we did on our first cluster where the pam module denies ssh access correctly).
We saw a similar issue whereby the way that we had PAM setup, meant that, and here I quote from SchedMD's Daniel Armengod:
----8<--------8<--------8<--------8<--------8<--------8<--------8<---- This is almost certainly caused by the fact that SSH's `keyboard-interactive` (not to be confused with `password`) AuthMethod forks a short-lived child process that is involved in the authentication logic. Slurm's pam_slurm_adopt module latches on to that process (which is the wrong one, of course) and things break in interesting ways from there.
SSH authmethods `publickey` and `password` do not exhibit this behaviour as SSH does not fork a child process to offload the authentication challenge-response dialogue to.
...
The key bit here is that in your last test you're forcing `PreferredAuthentications=password`, which isn't actually the `keyboard-interactive` AuthMethod that got picked before. They work differently under the hood, even if as far as the user is concerned, both methods just ask for a password.
...
In summary: try disabling the `keyboard-interactive` authentication method in your compute nodes. pam_slurm_adopt should work correctly now. ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
Maybe that's also your issue.
Daniel did say that SchedMD were going to update their documentation to make that distinction, and it's effect, more explciit, so I would expect it to be in the mainstream docs by now.
HTH