Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

How do you enable ssh login on OS X 10.8 (Mountain Lion) for a user with an empty password? I've seen others asking this question, and like me it's for the same reason: a parent who can't deal with passwords. So "set a password" is not an option.

I found references to adding "nullok" to various PAM config files. Didn't work. Found sshd config "PermitEmptyPasswords yes". Didn't work.

Updated info: A public/private ssh key pair is set up, and is being used successfully on my account (which has a password) on the same machine. File permissions for the ~/.ssh directory and private key are correct.

I've done a diff on "ssh -vvv" between a successful ssh with a password-enabled account and the one with no password.

54,55c54,55
< debug2: dh_gen_key: priv key bits set: 133/256
< debug2: bits set: 533/1024
---
> debug2: dh_gen_key: priv key bits set: 140/256
> debug2: bits set: 508/1024
67c67
< debug2: bits set: 509/1024
---
> debug2: bits set: 516/1024
79c79
< debug2: key: /Users/rae/.ssh/rae (0x7f9a0241e2c0)
---
> debug2: key: /Users/rae/.ssh/rae (0x7f81e0c1e2c0)
90,116c90,224
< debug1: Authentications that can continue: publickey,keyboard-interactive
< debug2: we did not send a packet, disable method
< debug3: authmethod_lookup keyboard-interactive
< debug3: remaining preferred: password
< debug3: authmethod_is_enabled keyboard-interactive
< debug1: Next authentication method: keyboard-interactive
< debug2: userauth_kbdint
< debug2: we sent a keyboard-interactive packet, wait for reply
< debug2: input_userauth_info_req
< debug2: input_userauth_info_req: num_prompts 1
< debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
< debug1: Authentications that can continue: publickey,keyboard-interactive
< debug2: userauth_kbdint
< debug2: we sent a keyboard-interactive packet, wait for reply
< debug2: input_userauth_info_req
< debug2: input_userauth_info_req: num_prompts 1
< debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
< debug1: Authentications that can continue: publickey,keyboard-interactive
< debug2: userauth_kbdint
< debug2: we sent a keyboard-interactive packet, wait for reply
< debug2: input_userauth_info_req
< debug2: input_userauth_info_req: num_prompts 1
< debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
< debug1: Authentications that can continue: publickey,keyboard-interactive
< debug2: we did not send a packet, disable method
< debug1: No more authentication methods to try.
< Permission denied (publickey,keyboard-interactive).
---
> debug1: Server accepts key: pkalg ssh-dss blen 433
> debug2: input_userauth_pk_ok: fp 6e:02:20:63:48:6a:08:99:b8:5f:12:d8:d5:3d:e1:fb
> debug3: sign_and_send_pubkey: DSA 6e:02:20:63:48:6a:08:99:b8:5f:12:d8:d5:3d:e1:fb
> debug1: read PEM private key done: type DSA
> debug1: Authentication succeeded (publickey).
> Authenticated to cme-mini.local ([192.168.1.5]:22).
> debug2: fd 7 setting O_NONBLOCK
> debug3: fd 8 is O_NONBLOCK
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_open: channel_new: 0
> debug2: channel 0: send open
> debug1: Requesting no-more-sessions@openssh.com
> debug1: Entering interactive session.
> debug2: callback start
> debug2: client_session2_setup: id 0
> debug2: fd 5 setting TCP_NODELAY
> debug2: channel 0: request pty-req confirm 1
> debug1: Sending environment.
share|improve this question

closed as off topic by Zoredache, Ward, voretaq7 Nov 6 '12 at 3:46

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
try using authentication keys for ssh. –  Laurentiu Roescu Nov 5 '12 at 15:52
    
"a parent who can't deal with passwords." -> Welcome but this website is not for home related question : serverfault.com/faq . –  coincoin Nov 5 '12 at 17:04
    
ssh keys are in place. Sorry, I should have mentioned I'm really trying to log in using an already set up private/public ssh key pair. These keys are valid and are being used for my account on the same machine. File permissions for the private key file are correct (read by user only, write by user only). As to "home related", I don't think configuring sshd to handle various password arrangements is a very typical "home" question. –  Reid Nov 5 '12 at 20:03
    
@Reid Typical or not, home questions are explicitly off topic per the FAQ. This is a fundamentally good question though - if you post the full ssh -vvv output from the unsuccessful login I'll move it over to Unix & Linux for you and take a look to see if I can figure out what's wrong -- reading a diff is screwing up all the context). (@ me in a comment once you've updated the question so I get notified -- if I don't spot the problem I'm sure someone on U&L will.) –  voretaq7 Nov 6 '12 at 3:46
    
@Reid (you may also want to look at the sshd logs. I think they're in in /var/log/secure.log on OS X, and that might tell you what the server doesn't like) –  voretaq7 Nov 6 '12 at 3:49

1 Answer 1

Allowing remote logins without password is asking for problems. Since you indicated that educating the user is not an option you are left with generating an ssh key. Those can be used without password, or with a passphrase (which is easier to remember).

According to the guide at this site that is easy to do.

share|improve this answer
    
There is a valid ssh key in ~/.ssh and still login is not possible. –  Reid Nov 5 '12 at 19:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.