# Removing user password



## MPaans (Nov 7, 2011)

Hi,

I'm looking for a quick command to remove a password from a user. I know of the lock feature, but that's not really what I'm looking for (I'll have to add scripts to unlock too, I think..).

I'm pretty sure I shouldn't remove the password manually from the master.passwd.. and I don't want to remove the user entirely either.. so what's left?

Thanks in advance for any input!


----------



## anomie (Nov 8, 2011)

To what end? _Why_ are you trying to remove a user password? If you explain the circumstances, you'll get a better answer. 

The first thing that comes to mind is vipw(8). Yes, that'd be manual.


----------



## fluca1978 (Nov 8, 2011)

If you don't want the user to be able to login you have to lock the account, or either set her shell to something like /bin/false (but I discourage this). If you want the user to login without having a password prompt I suggest using an ssh key-exchange instead.
Knowing what you are trying to achieve and why could help us giving better ideas.


----------



## MPaans (Nov 8, 2011)

I figured it out.. it was pretty easy!

[CMD=""]pw mod user "$USERNAME" -w no[/CMD]


----------



## fluca1978 (Nov 9, 2011)

I suspect you are using


```
pw mod user "$USER" -w [B]none[/B]
```

which sets a non-existent password for the user. I discourage this kind of approach as strongly insecure. Again, if your aim is not to prompt the user for a password, use ssh key-exchange authentication.


----------



## MPaans (Nov 9, 2011)

No, I'm using
[CMD=""]pw mod user "$USERNAME" -w no[/CMD]

From the man page

```
-w method     The -w option sets the default method used to set passwords
                   for newly created user accounts.  method is one of:

                         no      disable login on newly created accounts
                         yes     force the password to be the account name
                         none    force a blank password
                         random  generate a random password

                   The `random' or `no' methods are the most secure; in the
                   former case, pw generates a password and prints it to std-
                   out, which is suitable where you issue users with passwords
                   to access their accounts rather than having the user nomi-
                   nate their own (possibly poorly chosen) password.  The `no'
                   method requires that the superuser use passwd(1) to render
                   the account accessible with a password.
```

I tested with both 'no' and 'none', which respectively causes the password in master.passwd to be '*' and '' (blank).

I'm only using it for sendmail to allow relaying with valid user/pass. But even with a blank password, sendmail won't grant you access. But still, much better to set it to 'no' anyway.


----------



## anomie (Nov 9, 2011)

@MPaans: that's why I was asking those questions earlier in the thread. What you're really intending to do is disable shell logins for an account. (And there are other ways to reach that goal, incidentally.)


----------



## MPaans (Nov 10, 2011)

anomie said:
			
		

> @MPaans: that's why I was asking those questions earlier in the thread. What you're really intending to do is disable shell logins for an account. (And there are other ways to reach that goal, incidentally.)



No, what I'm intending to do is remove a password from a user. Not disable the shell login. And I just explained why..

But to keep things constructive: Is there any good reason not to do it this way, and if not, what would you recommend.


----------



## fluca1978 (Nov 10, 2011)

MPaans said:
			
		

> But to keep things constructive: Is there any good reason not to do it this way, and if not, what would you recommend.



On some mail server I configure the users to have no shell, that is they are unable to login and launch commands. This gives the ability to assign password and avoid users to log-in interactively, that seems what you want to achieve. But removing the password prevents a user to have any kind of access, even to a service, so it could be really secure under some circumstances.


----------

