On Fri, Aug 10, 2012 at 1:26 PM, Marc Weber <[email protected]> wrote: > If you use ubuntu or the like setting passwordAuthentication no is > sshd_config is enough because its set before usePAM is set. > > In NixOS the order is different which is why the description exists that > passwordAuthentication = no is likely to fail unless you also set usePAM > to no. > > I like the ruby principle: principle of least surprise. > > So I'd either ensure that the order is correct or that usePAM defaults > to no if you set passwordAuthentication to no. > > Now ensuring order is hard because the user can set extraConfig, should > it be added first or last or should it depend on merge order done by the > nixos configuration system? > > Thus forcing order explicitely this way would solve it: > > sshd_config_text = '' > ${nixos_config_by_options} > > ${etxraConfig} > ''; > > What do you think? Setting passwordAuthentication to no and passwords > are still accepted feels strange.
Some time ago (not sure if it still applies), I found that turning off password authentication indeed turns off ssh's plain-text(but ssh crypted) password authentication. The prompt you get is from the "challengeResponseAuthentication" method. It looks exactly the same as plain-text-password authentication, but uses a different algorithm. So when you put "passwordAuthentication = false; challengeResponseAuthentication = false" in your nixos config, you won't be prompted again. But I too think this is misleading, because what users probably want to achieve is to disallow authentication through a simple password. Perhaps we should change the option names to "authMethodPassword" and "authMethodChallengeResponse". Then some more user-friendly names such as "dontAllowPasswords" or "keysOnly" can set the right combinations of these for people who are not familiar with openssh's internals. > > Thoughts? > > Marc Weber > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
