I would like to understand your opinion a little more deeply. Are you suggesting that it's easier to (prepare the container and add a line at runtime) compared to (add a line to an sshd config at runtime)? The latter scenario would be the case if the patch is merged. Or did you mean that it's easier to prepare the container than to implement a correct patch into sshd to enable the option in the first place? If the patch is merged, then nobody has to prepare any containers a priori to enable this functionality. They just need to install sshd and create a config file whenever they need it, no root required. If the patch isn't merged, then anyone who wants to use this functionality has to prepare a container (unless they have root at runtime). They would then additionally have to create a config. ~Henry On Thu, Jun 27, 2024 at 2:49 PM Peter Moody <mindrot@xxxxxxxx> wrote: > i'm not a maintainer, but my personal opinion is that it's probably > easier to prepare a container with this pam configuration > > On Thu, Jun 27, 2024 at 2:26 PM Henry Qin <hq6@xxxxxxxxxxxxxxx> wrote: > > > > Thanks for the pointer! > > I played around with PamServiceName set to 'sshd_disable_auth' and got > it working with the minimum contents below in the file > /etc/pam.d/sshd_disable_auth. > > > > auth required pam_permit.so > > account required pam_permit.so > > session required pam_permit.so > > > > Thus, this does indeed enable disabling authentication. > > > > Unfortunately, as far as I can tell, only root can create files in > /etc/pam.d in most default system configurations. > > Moreover, it is somewhat common to disallow root in an actual deployed > environment. > > > > That means that this approach is infeasible when running sshd as an > ordinary user, both generally and in deployed environments, unless the > container or deployed VM already has a pam configuration file such as > /etc/pam.d/sshd_disable_auth deployed with it. > > > > Thus, I'm still interested in your opinions on the proposed patch, which > would grant more flexibility to ordinary users, and allow ad hoc usage in > deployed scenarios without having to prepare a container with a bespoke pam > configuration file. > > > > ~Henry > > > > On Thu, Jun 27, 2024 at 10:58 AM Peter Moody <mindrot@xxxxxxxx> wrote: > >> > >> see pam_permit(8) > >> > >> > >> On Thu, Jun 27, 2024 at 10:37 AM Henry Qin <hq6@xxxxxxxxxxxxxxx> wrote: > >> > > >> > When I looked at `man pam_unix`, I did not see any obvious options > that > >> > would > >> > cause ssh to authenticate without prompting for a password at all, > short of > >> > setting an empty password which is similar to PermitEmptyPasswords > option. > >> > > >> > However, I am not very familiar with the internals of PAM, so > pointers to > >> > documentation would be greatly appreciated. > >> > > >> > Also, I think adding a single line to sshd_config is simpler for most > users > >> > to > >> > do correctly than configuring an alternate PAM stack without breaking > their > >> > primary sshd setup, which is why I think the patch may still be > useful. > >> > > >> > On Thu, Jun 27, 2024 at 7:57 AM Carson Gaspar <carson@xxxxxxxxxx> > wrote: > >> > > >> > > On 6/26/2024 9:34 PM, Henry Qin wrote: > >> > > > Hi folks, > >> > > > > >> > > > I've recently started to work on a patch for openssh that > introduces a > >> > > new > >> > > > option to disable authentication. > >> > > > I'd like to explain why I think this might be generally useful, > and > >> > > solicit > >> > > > opinions on whether such a patch would be acceptable to the > maintainers > >> > > as > >> > > > a pull request. > >> > > > >> > > Why not just use a different PAM stack? The new release allows > >> > > specifying the stack name. This should do what you want with no code > >> > > changes using Password / KbdInteractive AuthN. > >> > > > >> > > -- > >> > > > >> > > Carson > >> > > > >> > > _______________________________________________ > >> > > openssh-unix-dev mailing list > >> > > openssh-unix-dev@xxxxxxxxxxx > >> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > > > >> > _______________________________________________ > >> > openssh-unix-dev mailing list > >> > openssh-unix-dev@xxxxxxxxxxx > >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
