In this answer, is was suggested that the UNIX way of adding a ! in front of the password field would work. I claim that this is not a clean solution. It will not make logins impossible, but merely it changes the password to the literal content of the password field (of which the first character is !).

For example, assume the password field now looks like this:


Here, xxx stands for the salt, and yyy for the hash. That string will now be the user's password. For many practical purposes, this means the user cannot log in anymore, since she does not know her salt. But, in theory, by guessing the salt, login is still possible. Even worse, if an attacker obtains the LDAP database, he can now easily log in to this "locked" account, since hashing apparently is no longer used.

How can it be done instead?

  • 1
    I believe you are correct. You should reformulate this a Q&A pair. – Sven Sep 14 at 11:23
  • Note that just adding the ! right after the {CRYPT} should work as well. The same is true if you use the builtin hash methods like {SHA} or {SHA512}. That might make it easier to do this in a script if you just have to replace } with }!. – Sven Sep 14 at 11:31
  • Very important though: Doing this does not prevent users from logging in with an SSH key, as in that case, LDAP is never asked if the PW is correct. Set the shell to /bin/false for that case (as a first step). – Sven Sep 14 at 11:36
  • Indeed, very important point. I'm now wondering: which cases are not covered by setting shell to /bin/false as the only measure? – Lasse Kliemann Sep 14 at 11:45
  • One short test: I am using sssd, which caches user entries, including the shell. Until the cache entry expires or gets flushed, you can still login with the key and change back your shell (I guess nscd would act similar). Better remove the authorized_keys file. In one older environment I run, my user deactivation process includes renaming authorized_keys and replacing it with an empty one owned by root with 600 permissions. – Sven Sep 14 at 12:23

Change the password field to the following:


Or the following:


According to my tests, this makes password authentication impossible.

It does not, however, cover other ways of authentication, for example with an SSH key. In order to cover those, at least the shell should be set to /bin/false. I strongly recommend to combine this with another measure. In the comments, it was suggested to disable ~/.ssh/authorized_keys. A probably safer way is to change the primary group of the user to a group that is not allowed to SSH into the machine (the DenyGroups or AllowGroups feature of SSHD can be used for this).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.