5

As much as I would like to figure out the problem, at this point too much time has been invested in deleting a stupid key when I already had a solution (the command line creation) that works. I'm going to delete the user and run the commands that I need. It would still be wonderful to have an answer, but I don't think that is going to happen.

I have a network of slaves attached to buildbot, each with a buildbot user account. I'd like their accounts to not have passwords (read: not an empty password). I did this successfully on one of the boxes as a great consequence of remotely creating the user and not setting the password in the procedure.

Two other OSX machines that I set up through the GUI do have passwords, and I'm wondering if there is a way to remove the password without leaving it empty. I looked through a bit of the documentation for dscl and passwd, but they don't have the options I'm looking for. I could set them to be some random string of numbers. Would that be just as effective? Is my description equivalent to having an empty password and locking the account (as in this disscussion for linux)? If so, how do I lock an OSX account?

The second part of my question is in regard to the way that I originally created the users. Below are the commands and they seem to work fine but I wonder if I'm missing some important setting --the buildslave did start and execute jobs though.

sudo dscl . -create /Users/buildbot
sudo dscl . -create /Users/buildbot UserShell /bin/bash
sudo dscl . -create /Users/buildbot RealName "BuildBot"
sudo dscl . -create /Users/buildbot UniqueID <ID>
sudo dscl . -create /Users/buildbot PrimaryGroupID 61
sudo dscl . -create /Users/buildbot NFSHomeDirectory /Users/buildbot
sudo mkdir /Users/buildbot
sudo chown buildbot /Users/buildbot

EDIT: For the machines that already had accounts w/ passwords created through the System Preferences, the commands suggested by Dan Black do not actually delete the Password key, 

sudo dscl . -delete /Users/buildbot Password
sudo dscl . -read /Users/buildbot Password

The output to the second command is, 

Password: *******

Continuing as if the password was deleted, I run 

sudo dscl . -create /Users/buildbot Password '*'
su buildbot

And the previous password accesses the account. This is on OSX 10.5.8 and 10.6.8. 

sudo dscl . -change /Users/buildbot Password 'OLDPASS' '*'
su buildbot

This also does not change the password, and OLDPASS can switch users when asked for the password.

Here is the complete key-value pair output for the user i'm having trouble with --created through sys-preferences. To clarify an inconsistency, this machine uses user 'developer' not 'buildbot', but the previous commands were all done the same just with the obvious replacement

Amoy:~ lyn$ sudo dscl . -read /Users/developer
dsAttrTypeNative:_writers_hint: developer
dsAttrTypeNative:_writers_jpegphoto: developer
dsAttrTypeNative:_writers_LinkedIdentity: developer
dsAttrTypeNative:_writers_passwd: developer
dsAttrTypeNative:_writers_picture: developer
dsAttrTypeNative:_writers_realname: developer
dsAttrTypeNative:_writers_UserCertificate: developer
AppleMetaNodeLocation: /Local/Default
AuthenticationAuthority: ;ShadowHash; ;Kerberosv5;;developer@LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;
AuthenticationHint:
 developer for auto testing
GeneratedUID: BF95A834-A7F1-4DDD-8DFB-6B80B8120CA7
NFSHomeDirectory: /Users/developer
Password: ********
Picture:
 /Library/User Pictures/Fun/Flippers.tif
PrimaryGroupID: 20
RealName: Developer
RecordName: developer
RecordType: dsRecTypeStandard:Users
UniqueID: 512
UserShell: /bin/bash
Community
  • 1
nlucaroni
  • 192
  • 1
  • 9
  • I'm confused: you want them to not have a password, but not have a blank password? – Canadian Luke Jan 10 '12 at 16:30
  • yeah. I guess the same affect may be having a blank password and locking the account? (from looking around,http://unix.stackexchange.com/questions/7283/how-can-i-make-a-user-able-to-log-in-with-ssh-keys-but-not-with-a-password). Would this be correct? – nlucaroni Jan 10 '12 at 16:41
  • That looks right, but I didn't quite understand your question based on wording alone. I would recommend editing it to say so, and if that is the answer, paste what was said and give credit as an answer – Canadian Luke Jan 10 '12 at 17:27
  • No it's not right for OSX; `passwd -l` is for location not lock. I edited the question accordingly. Does it need further clarification? I thought I was being pretty precise. – nlucaroni Jan 10 '12 at 17:34
  • My confusion came from your second sentance, that's all. And the OSX part is what drew me in, but I don't use dscl to make users, I use the GUI part – Canadian Luke Jan 10 '12 at 17:45
  • What version of OS X is this? Can you reproduce this behavior of being unable to delete the `Password` entry with a new account created using System Preferences? – Daniel Beck Jan 10 '12 at 18:45
  • Are you ignoring `dscl` program output? That last command, `change`, has a different syntax. The page of error output should tell you... – Daniel Beck Jan 10 '12 at 18:52
  • I'm sorry, I mistyped, it should have been create. – nlucaroni Jan 10 '12 at 18:54
  • Just curious, what's the output of `dscl . -read /Users/username` for a user that was entirely created using the GUI? – Daniel Beck Jan 10 '12 at 20:31
  • Can you reproduce the behavior with a new user account just created using System Preferences? – Daniel Beck Jan 10 '12 at 20:56
  • As much as I would like to figure out the problem, at this point too much time has been invested in deleting a stupid key when I already had a solution (the command line creation) that works. I'm going to delete the user and run the commands that I need. It would still be wonderful to have an answer, but I don't think that is going to happen. – nlucaroni Jan 10 '12 at 20:57
  • Dan, I'm not going to do that. I've done this on three systems with the same results, so I think that isn't necessary. – nlucaroni Jan 10 '12 at 21:00

2 Answers2

3

You need to set the password to a single * character (asterisk, star) using dscl.

sudo dscl . -create /Users/buildbot Password '*'

Be sure to escape or quote (as shown) it so it doesn't get interpreted by your shell.

This will (when read) not be displayed as ******** like any other password, but as *, which just means "no password".

Daniel Beck
  • 109,300
  • 14
  • 287
  • 334
  • It's probably derived from the use of a `*` in `passwd` files that only contain password hashes to indicate that a user has no password. – Daniel Beck Jan 10 '12 at 18:10
  • This did not update the password; after executing the command I can still use the old password. is it possible that it should be `-change` instead of `-create`? – nlucaroni Jan 10 '12 at 18:20
  • 1
    @nlucaroni Did you `-delete /Users/buildbot Password` before executing that line? My reference starting point was the code in your question, which didn't mention creation of a password. – Daniel Beck Jan 10 '12 at 18:21
  • No, I did not delete anything; I thought you were referring to my earlier made accounts. Do I have to do this to the newly created account through the command line? It appears to be doing what I want without setting that key at all. – nlucaroni Jan 10 '12 at 18:24
  • @nlucaroni Now I understand what you mean. It's difficult with multiple questions combined into one. Run `dscl` with the arguments in my earlier comment first to delete the old password, then set the new one to `'*'`. `-change` might work, I haven't tested it myself though. What do you mean by *without setting that key at all*? What's the output of `dscl . -read /Users/buildbot Password`? – Daniel Beck Jan 10 '12 at 18:27
  • I deleted the key, and then created one as you prescribed on the machines with accounts that already had passwords, but I can still log in with the old account password. I am guessing I'll have to restart the box? (I cannot do it now to test this). "without setting the key" was referring to my account created via the command line by the commands I listed above, that one seems to be working fine without setting a key or needing to set it to '*'. – nlucaroni Jan 10 '12 at 18:28
  • @nlucaroni Cannot reproduce. If I set the password through System Preferences (it's an account created through the GUI), I can e.g. `su` to that account using the password I set. Then I just `sudo dscl . -create /Users/name Password '*'` and `su` fails. *How* are you logging into that account after removing the password? Remember that root can `su` into any account, and e.g. SSH keys will still work to authenticate SSH clients. – Daniel Beck Jan 10 '12 at 18:31
  • Delete isn't deleting the key. when I read the value on the machine that never had a password set I get the expected, no such key. but when I run the command on the other box, after a delete, i get '*****'. – nlucaroni Jan 10 '12 at 18:33
  • I open a new terminal (to avoid sudo permissions still active) and using `su` – nlucaroni Jan 10 '12 at 18:34
  • @nlucaroni Please add the precise sequence of commands you execute to your question. This shouldn't happen. What version of OS X are you using? – Daniel Beck Jan 10 '12 at 18:35
  • @nlucaroni `su` doesn't use `sudo`, they are completely independent. `su` asks for the target account's password, `sudo` for your own. Don't use `sudo su`, just run `su buildbot` to get queried for buildbot's password. – Daniel Beck Jan 10 '12 at 18:36
  • yeah i know what the difference is and I didn't use `sudo su`. I meant, since sudo was used to change the keys, the terminal still was unlocked. I guess it doesn't matter since I didn't use sudo anyway in the command, I was just being 100% sure since I'm not a usual OSX user. – nlucaroni Jan 10 '12 at 18:40
2

I think the problem you're having with @Daniel Beck's answer is that the password isn't stored in the user record's Password attribute, but as a shadow hash file in /var/db/shadow/hash/USERGUID, and the AuthenticationAuthority attribute still points to that. This seems to work for me:

sudo dscl . -delete /Users/buildbot AuthenticationAuthority
buildbotGUID=$(dscl . -read /Users/buildbot GeneratedUID | awk '{print $2}')
sudo rm "/var/db/shadow/hash/$buildbotGUID" "/var/db/shadow/hash/$buildbotGUID.state"

Ideally, you should also remove the account's Kerberos principal (OS X clients run their own "local" Kerberos realm, and it occasionally gets underfoot). But that's a bit more complicated, and I think depends a fair bit on which version of OS X you're using.

BTW, if the above doesn't completely do the trick, try this:

sudo dscl . -create /Users/buildbot AuthenticationAuthority ";DisabledUser;"
Gordon Davisson
  • 34,084
  • 5
  • 66
  • 70
  • Disabling the account is functionally equivalent to locking it? – nlucaroni Jan 11 '12 at 00:24
  • Mostly; there are probably some subtle differences. Note that the "disabled" setting is in the AuthenticationAuthority attribute, so generally it only disables authentication, not other account functions. I don't know enough about buildbot to know this will interfere with it. – Gordon Davisson Jan 11 '12 at 01:10