other characters beside * in /etc/passwd?

Does anyone here know of any other characters that can be used in a Unix passwd file to denote certain things about an account? I read somewhere that any non-alphanumeric character at the beginning of a password entry in the /etc/passwd file would disable the password, but some characters must have more meaning than others. For example, I know that the "*" denotes that the account is disabled not allowing users to log in. However, I just discovered on my Slackware Linux distro that you can still log into a disabled account using public-key authentication over SSH even if the account has a "*" in the passwd file. If an account has a "*" in the passwd file on an HP-UX system, however, public-key authentication is denied. I was told that a "!!" in the /etc/passwd file on an HP-UX system would allow public-key authentication, but deny standard telnet. Unfortunately, I can't test that. I have been unable to find any documentation on characters other than "*" used in /etc/passwd files. Does anyone here know of any others and what they do, exactly?

Hmmm... thats strange. I can't help you with the charcters in the /etc/passwd file... but

Can you just restrict that user in the sshd_config file?

AllowUsers user1 user2 userX
DenyUsers *

The same can be done with groups.

AllowGroups group1 group2 groupX
DenyGroups *

I think if you were to use them together, then you'd have to put them in order.

AllowUsers user1 user2 userX
AllowGroups group1 group2 groupX
DenyUsers *
DenyGroups *

Hope I have the syntax correct. I don't have access to a config file at the moment.
Just going from memory.
Doesn't really answer your question... I know. It was just a thought.

That is why when I disable accounts, I not only lock it but set their shell to /bin/false (or noshell/nologin if on a system that has it). That should fix the problem of someone logging in via public/private key syntax. In Solaris if memory serves, in the /etc/shadow file it uses *LK* for a locked account (think I have also seen *NP*). On my FC3 box, I see both !! and * ... can't really see a rhyme or reason to it though...

I was just coming back to edit my post and saw that neb mentioned changing the shell.
I was just going to suggest that. You can even set it so when they try to login, it will show them a message saying it is disabled...
http://www.linux.com/guides/sag/x2466.shtml

I'm not *nix admin. I just use it on my personal networks and for myself only.
I have very little experience managing user accounts...

We should not attempt to guess what the format of /etc/passwd is, but rather assume that the authors of the "passwd" program (and its associated libraries) got it right.

Therefore, if you want to lock and account, use the program to do it:

Code:

---

passwd -l account

---

Slarty

ros, I wonder if pub-key-authentication for sshd is not really 'parsing' or 'processing' the account info from /etc/passwd. I really don't have much detail on this, but I can tell you from experience that if you have users who login to *NIX with an RSA SecurID Token, you have to change their default shell to something like /usr/bin/securid (or whatever the bin/link is to the RSA authentication agent software). Their actual system shell is then stored in their user record in the Auth server db.

Just some food for thought.

Hello,

Don't know if this will help... I wrote a small C program and listed it in /etc/shells call denylogin

Rather then trying to mess with the particulars of varying Linux Distros, just change the shell.

Here's the code I use:

Code:

---

// DenyLogin - Shell replacement for /etc/shells that will block loging to an account with this as a shell.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
  {
    printf("\n\nAccess to this account is *NOT* allowed!\n\n");

    return(0);
  }

---

Compile with

gcc -o denylogin denylogin.c

copy the denylogin to /sbin

Here is the infamous "nobody" user from my passwd:

nobody:x:99:99:nobody:/:/sbin/denylogin


Just incase a hacker trys to get smart. I did this too all of my accounts that I wanted no one to login to. The message in the printf line can be anything you want. This could easily be expanded to a "ill-fortune" type prorgram on the similarity to fortune, but on the sarcastic side... Something to have fun with...

Thanks for all the replies folks. I don't think I made my question clear, though. There are lots of ways to deny someone access to a system rather than just using the /etc/passwd file, and most of them came out in this thread (ie, setting the shell to a dummy shell, using the passwd binary, etc). I guess what I really wanted to know is if someone knew of a document listing the different characters that appear in /etc/passwd files and what they meant, but it seems from the different posts here that the only common character used in the /etc/passwd file for all the *nix flavors is the "*". All others seem to be unique to each *nix flavor.

zen -- You may be right about the sshd daemon not parsing the /etc/passwd file on Linux, but it does seem to pay attention to that file on HP-UX. When that password is set to * on HP-UX, ssh will NOT let me log in as an authenticated public-key user. As soon as that password is set to something else, however, I can slide right in. For Linux, however, the /etc/passwd file does appear to be completely ignored. Unfortunately, the "documentation" for OpenSSH amounts to 6-7 man pages. You would think there would be more info about this protocol by now. :bigsmile:

Thanks everyone for their posts!

Hi

These are the special characters I know/heard of:

Code:

---

x          : password is in /etc/shadow
*,X        : invalid password
[empty]    : no password set. should be changed after first login by the user.
!          : redirection to /etc/security/passwd
!!          : (HP-UX) allow ssh, albeit invalid password, no rhosts, no direct login
NOLOGIN    : (HP-UX) allow ssh and rhosts, no direct login

---

An idea to explain what you observe: * denotes that the password is invalid.
If the field has an * and a password is required for user authentication,
the user cannot log in. In a few distros/flavours, they seem to interpret
this rule like the HP-UX (no login at all, except ssh (public key) if the (invalid)
password is provided by !!), others might allow access if some form of
authentication is provided, like via public-key.


Cheers.

/edit: for completeness, NOLOGIN added. Credits to roswell.