Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Aug 2020 11:13:42 +0000
From:      Grzegorz Junka <>
To:        Polytropon <>
Subject:   Re: Verify user password
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On 15/08/2020 18:49, Polytropon wrote:
> On Sat, 15 Aug 2020 12:39:06 +0000, Grzegorz Junka wrote:
>> How can I verify if a given password matches the password stored in
>> master.passwd database for a user account that is set up with
>> /nonexistent and /usr/sbin/nologin (so a user that can't normally login
>> to the system but still can have a password stored in the database)?
> First of all, /nonexistent and /usr/sbin/nologin have different
> purposes: if after a successful login the user's interactive shell
> is to be executed, /nonexistent leads to a "cannot find that program
> to execute, exiting right now" situation, while /usr/sbin/nologin
> can actually be executed and then displays an error message and
> exits, terminating the session.
> See "man 1 login" and "man 1 nologin" for details.
> Regarding password verification:
> If you have read access to /etc/master.passwd and the clear text
> password of a user, you can use the crypt() function to generate
> the encrypted password, and then compare that. I think that is
> what you try to do, correct?
> provided: 	plain-text password P from somewhere
> 		encrypted password E from /etc/master.passwd
> intended:	is crypt(P) == E?
> approach:	P' = crypt(P)
> 		test if P' == S
> This is of course very simplified. :-)
> See "man 5 passwd" and especially "man 3 crypt" for details.

Yes, the intention is that the user only has an entry in the 
master.passwd file (so that sendmail service can verify the password 
against an entry there). It should not be possible for the user to login 
(meaning, they should not be able to open an interactive session as that 

I did found some manuals that explain how to generate the password, 
especially when using different hashing than the default one and store 
such password in the master.passwd. That could work, I just hoped that 
there is a command line utility that is able to verify the password in 
the same way the system or any service would do without the trickery of 
fetching the password from master.passwd, verifying the encryption 
scheme, encrypting the password with the same scheme, then finally 
testing if they are the same.



Want to link to this message? Use this URL: <>