what does star in passwd file mean?

I have a computer that I need to boot into, but the passwords seem to be bogus. Additionally I can’t mount the drive for writing, and it is a mips processor, so I can’t stick it in another machine to run it.

Anyhow, they passwd file has some users that look like this, with a star after the user-name. does that mean blank password or what?

sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh
diag:*:0:996:Hardware Diagnostics:/usr/diags:/bin/csh
bin:*:2:2:System Tools Owner:/bin:/dev/null
uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh
sys:*:4:0:System Activity Owner:/var/adm:/bin/sh
adm:*:5:3:Accounting Files Owner:/var/adm:/bin/sh
lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh
nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico
auditor:*:11:0:Audit Activity Owner:/auditor:/bin/sh
dbadmin:*:12:0:Security Database Owner:/dbadmin:/bin/sh
rfindd:*:66:1:Rfind Daemon and Fsdump:/var/rfindd:/bin/sh
Asked By: j0h


This means that it is disabled for direct login. It is a user that is used for running services or to be used for rlogin. Check https://en.wikipedia.org/wiki/Passwd#Password_file

Answered By: Marco

You have to check man passwd:

If the encrypted password is set to an asterisk (*), the user will be
unable to login using login(1), but may still login using rlogin(1),
run existing processes and initiate new ones through rsh(1), cron(8),
at(1), or mail filters, etc. Trying to lock an account by simply
changing the shell field yields the same result and additionally
allows the use of su(1).

Usually accounts with * in password field don’t have a password e.g: disabled for login. This is different to account without password which means the password field will be empty and which is nearly always a bad practice.

Answered By: taliezin

The accounts with passwords are the accounts with a glob of base64 gibberish in the second field:

lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh

This computer appears to be using the traditional, DES-based crypt(3) password hash. This hash is quite weak by modern standards; if you can’t manage to get a root login any other way, you can probably brute-force recover the password, using John the Ripper or similar software. Also, technically that is not base64 but an older, similar encoding, but you probably needn’t worry about that.

The distinction between :*: and :!: mentioned in other answers is too new to be relevant to your problem. On a UNIX system this old, there are only three different things that can appear in the password field:

alice::1001:1001:Alice Can Log In Without A Password:/home/alice:/bin/ksh
bob:WSy1W41d4D1Gw:1002:1002:Bob Must Supply A Password:/home/bob:/bin/ksh
carol:ANYTHING ELSE:1003:1003:Carol Cannot Log In At All:/home/carol:/bin/ksh

If the contents of the password field are empty, you can log in with no password.

If the contents of the field are the valid crypt hash of some password, you can log in with that password.

Otherwise you can’t log in as that user. * is just the conventional thing to use – it’s visually obviously not a valid password hash. It was probably picked by whoever wrote the passwd program.

(The point of having user IDs in the password file who can’t log in is that they can still own files, they can still have cron jobs, and daemons can use setuid to assume that identity. In fact, it’s best practice to run all daemons (that don’t have to run as root) under such user IDs, so that you have some level of assurance that only the daemon is running under that identity.)

(The accounts with /dev/null in the shell field are locked out against root using su to run programs under that user identity, as well as regular login. Nowadays you are much more likely to see /bin/false or /sbin/nologin used for that purpose; I suspect that on this system the latter does not exist and the former is a shell script.)

(The password for Bob is “bobpassw”, encrypted using the old algorithm, but on a modern Linux machine; it might not be what your computer would produce for the same password and salt. One of the reasons the old algorithm is considered no good anymore is it has a hard upper limit of 8 characters in a password.)

(I know the system is really old because it’s using DES-based password hashing, because it isn’t using a shadow file, and because root’s shell is /bin/ksh rather than anything newer and more ergonomic.)

Answered By: zwol

About your actual question, see taliezin’s answer (and accept that one 😉

About your other problem: Search for the string 8sh9JBUR0VYeQ on the disk to figure out the disk block(s) it resides in. Then dd that disk block(s) into a file, replace that string with a known password hash (the old crypt() one – same length) and write the disk block(s) back to the old location – possibly doing a full backup of the disk before. Since this approach doesn’t change the size of the file, no file system meta data need to be updated.

Answered By: Bodo Thiesen
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.