On Thu, Jul 21, 2016 at 2:00 PM, Morham Anthelleron
<opensshdev@xxxxxxxxxxx> wrote:
[...]
> Since OpenSSH already makes use of an unprivileged user for privsep, why not
> take the next step of setting a (long) random password for it using the
> system's normal shadow password routines?
Assuming you mean putpwent(): that requires an encrypted string to put
in pw_passwd putting us right back where we started.
> If one is concerned about an accidentally "successful" login, you could
> perturb the supplied passphrase prior to passing it down to the authentication
> library to ensure a successful entry is impossible.
>
> Alternately, a second "dummy" account that's not used at all by the system
> which is a chroot jail with nothing in it with a random password?
If we could reliably come up with the encrypted string to put in that
dummy account we wouldn't need the dummy account.
Actually setting a password is quite system dependent. exec'ing
/bin/passwd in most cases needs a controlling terminal although some
have flags for reading form stdin. Using pam_chauthtok() would
require making assumptions about what the prompts were. Some systems
enforce complexity (as opposed to entropy) requirements. And then
you'd have an account with a password that you're not quite sure where
it came from.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
