Como você habilita o login ssh no OS X 10.8 (Mountain Lion) para um usuário com uma senha vazia? Já vi outros fazerem essa pergunta e, como eu, é pelo mesmo motivo: um pai que não consegue lidar com senhas. Então, "definir uma senha" não é uma opção.
Eu encontrei referências para adicionar "nullok" a vários arquivos de configuração do PAM. Não funcionou. Encontrado sshd config "PermitEmptyPasswords yes". Não funcionou.
Informações atualizadas: Um par de chaves ssh público / privado está configurado e está sendo usado com sucesso na minha conta (que possui uma senha) na mesma máquina. As permissões de arquivo para o diretório ~ / .ssh e a chave privada estão corretas.
Eu fiz um diff em "ssh -vvv" entre um ssh bem-sucedido com uma conta ativada por senha e a outra sem senha.
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 [email protected]
> 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.
Permitir logins remotos sem senha está solicitando problemas. Desde que você indicou que educar o usuário não é uma opção, você fica com a geração de uma chave ssh. Esses podem ser usados sem senha ou com uma senha (que é mais fácil de lembrar).
De acordo com o guia em este site que é fácil de fazer.