Proposal to add a DisableAuthentication option to sshd ServerOptions

[Henry Qin]

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 at hda3.com> 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 at cs.stanford.edu> 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 at hda3.com> wrote:
> >>
> >> see pam_permit(8)
> >>
> >>
> >> On Thu, Jun 27, 2024 at 10:37 AM Henry Qin <hq6 at cs.stanford.edu> 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 at taltos.org>
> 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 at mindrot.org
> >> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >> > >
> >> > _______________________________________________
> >> > openssh-unix-dev mailing list
> >> > openssh-unix-dev at mindrot.org
> >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>