On Sat, Feb 21, 2026 at 02:53:43PM +0000, Eric Johnson wrote:
> On Saturday, February 21st, 2026 at 04:44, Crystal Kolipe <kolipe.c@exoticsilicon.com> wrote:
>
> > On Sat, Feb 21, 2026 at 07:27:54AM +0000, Eric Johnson wrote:
> > > If you want random passwords, why not just use
> > > openssl rand -base64 32
> > > or
> > > openssl rand -hex 32
> > >
> > > What I have done in the past was create passwords with:
> > > openssl rand -hex 60
> > > for user accounts that are intended to only be used via ssh with ssh keys.
> >
> > I'm presuming that the intention of the OP was to make a accounts with an
> > unknown password, (long and random), for a purpose such as this.
> >
> > A very good idea would be to read the manual page for passwd(5), (so
> > 'man 5 passwd').
> >
> > There you will find some very useful advice, specifically that accounts that
> > are not intended to be logged in to are set up with a single asterisk in the
> > password field.
> >
> > No need for random junk random passwords.
>
> For what I stated, the purpose was not to have accounts that
> could not be logged into, but could be logged into normally
> only with a ssh key.
The asterisk in the password field technique does not prevent login by
external means such as ssh. So it is a valid, (and likely preferable), way to
achieve what you are describing.
> Sure, "AuthenticationMethods publickey" would do that,
Not exactly. On it's own, that just prevents password-based logins _via ssh_.
Local users can still log in to an account that has a valid password, unless
you take other steps to prevent that.
> but
> then another admin with root privileges could change that to
> "AuthenticationMethods password publickey".
This is not directly related to the password file.
At this point we are now discussing different ways to achieve similar and
related things. There is some overlap, and in fact the two techniques
compliment each other.
> Using 13 asterisks would likely work okay -- I haven't tried
> that. I assume that 13 asterisks would still permit S/Key
> which I typically set up for every account to permit a console
> login, if necessary (it rarely is necessary from anything but
> admin accounts).
There is nothing special about the asterisk character in the encrypted
password field. Nor is there anything special about using one or multiple
asterisk characters.
If the encrypted password field does not contain a string, (or if we want to
be pedantic about terminology, then 'octet-stream'), that represents one or
more encryped passwords, (as defined by the cipher in use, which on OpenBSD
will be bcrypt), then by definition it is not possible to authenticate using
it, (unless the login code is buggy).
That does nothing to prevent authentication by methods which ignore the
encrypted password field of the password file, such as SSH when using
key-based auth.
So you can quite happily put '*' in the password field of 'root' or whatever
accounts you don't want to be authenticated via 'traditional' means.
Then you can also configure ssh to only allow public key authentication.
> That said, I like the idea that if someone should somehow
> manage to get my /etc/master.passwd file, I would rather not
> point out to them the two or three admin accounts that are
> protected by normal passwords (here, that is typically 20
> to 30 character pass phrases). I'd rather they see 100
> password protected accounts and not give them any idea
> which ones to apply a password cracker to.
I can see your line of thinking, but the real-world utility of that seems a
bit limited.
If they managed to get /etc/master.passwd, they can likely get /etc/group and
see who is in group wheel.
Even without /etc/group, if the admin users are in a different login class
then there is enough information in master.passwd to deduce which accounts
to go after first.
In any case, if you want something in the password field that looks like an
encrypted password to the casual observer but is actually non-functional, then
there are much better ways to do that than what the OP was trying to do.
Passing a random value to /usr/bin/encrypt is always going to create a _valid_
hashed password, even if the supplied cleartext input to /usr/bin/encrypt was
a complicated string of symbols.
No comments:
Post a Comment