| Message ID | 20190319114156.10696-1-esben.haabendal@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [RFC] openssh: add option to allow login as root | expand |
On 2019-03-19, Esben Haabendal <esben.haabendal@gmail.com> wrote: > What do you think. Is this kind of micro-management of a > configuration file something that I should keep out of tree? I don't have a strong opinion either way. I've always done things like that (including that exact setting change) with a postbuild script. That works well for me, and it's actually kind of nice having all those custom configuration changes in that one place.
>>>>> "Esben" == Esben Haabendal <esben.haabendal@gmail.com> writes: > From: Esben Haabendal <esben@haabendal.dk> > What do you think. Is this kind of micro-management of a configuration > file something that I should keep out of tree? We discussed it tonight on IRC and didn't really get to a good compromise. On one hand, we prefer to stick with upstream defaults (especially when security is involved), but it is true that dropbear allows root logins by default. We prefer to not add configuration options for these kind of detailed policy decisions, as openssh has a LOT of other configuration options - But silently allowing root logins when we have "always" disallowed it in the past also isn't nice. So all in all, this kind of policy tweaks are better done in a post build script.
On 19/03/2019 23:42, Peter Korsgaard wrote: >>>>>> "Esben" == Esben Haabendal <esben.haabendal@gmail.com> writes: > > > From: Esben Haabendal <esben@haabendal.dk> > > What do you think. Is this kind of micro-management of a configuration > > file something that I should keep out of tree? > > We discussed it tonight on IRC and didn't really get to a good compromise. > > On one hand, we prefer to stick with upstream defaults (especially when > security is involved) This patch doesn't change the defaults. > , but it is true that dropbear allows root logins > by default. It's not nice that the default for dropbear and ssh is different, but that has little to do with deciding if this kind of configurability is relevant or not. > We prefer to not add configuration options for these kind of > detailed policy decisions, *That* is the crux of the matter. We normally only have configurability of compile-time options, and assume that anything else is handled in post-build scripts. The (only?) exception to that principle is the system menu. So *maybe* something global in the system menu could work, and then dropbear and openssh and whatnot would do whatever is needed to permit/disallow root login for that particular package. But I'm not exactly ecstatic about that option. > as openssh has a LOT of other configuration > options True, but permitting root login is clearly one that is a lot more important/relevant than all the others. Currently, the typical user will naively enable openssh, then try to ssh into the device, and fail... > But silently allowing root logins when we have "always" > disallowed it in the past also isn't nice. This is *definitely* a no-no. > So all in all, this kind of policy tweaks are better done in a post > build script. In the few projects where I've seen openssh used, it was always with a custom config file. Otherwise, there's not much reason to use openssh instead of dropbear I guess. Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> We discussed it tonight on IRC and didn't really get to a good compromise. >> >> On one hand, we prefer to stick with upstream defaults (especially when >> security is involved) > This patch doesn't change the defaults. No, but the discussion on IRC included talking about if there should be an option or if we should unconditionally allow/disallow root logins. >> We prefer to not add configuration options for these kind of >> detailed policy decisions, > *That* is the crux of the matter. We normally only have configurability of > compile-time options, and assume that anything else is handled in post-build > scripts. The (only?) exception to that principle is the system menu. > So *maybe* something global in the system menu could work, and then dropbear > and openssh and whatnot would do whatever is needed to permit/disallow root > login for that particular package. But I'm not exactly ecstatic about that option. Me neither. >> as openssh has a LOT of other configuration >> options > True, but permitting root login is clearly one that is a lot more > important/relevant than all the others. Currently, the typical user will naively > enable openssh, then try to ssh into the device, and fail... Correct. It will also fail for dropbear as the root user by default does not have a password set. >> So all in all, this kind of policy tweaks are better done in a post >> build script. > In the few projects where I've seen openssh used, it was always with a custom > config file. Otherwise, there's not much reason to use openssh instead of > dropbear I guess. Indeed. I always use dropbear as well.
On Wed, Mar 20, 2019 at 2:58 AM Peter Korsgaard <peter@korsgaard.com> wrote: > > >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > > Hi, > > >> We discussed it tonight on IRC and didn't really get to a good compromise. > >> > >> On one hand, we prefer to stick with upstream defaults (especially when > >> security is involved) > > > This patch doesn't change the defaults. > > No, but the discussion on IRC included talking about if there should be > an option or if we should unconditionally allow/disallow root logins. > > >> We prefer to not add configuration options for these kind of > >> detailed policy decisions, > > > *That* is the crux of the matter. We normally only have configurability of > > compile-time options, and assume that anything else is handled in post-build > > scripts. The (only?) exception to that principle is the system menu. > > > So *maybe* something global in the system menu could work, and then dropbear > > and openssh and whatnot would do whatever is needed to permit/disallow root > > login for that particular package. But I'm not exactly ecstatic about that option. > > Me neither. > > > >> as openssh has a LOT of other configuration > >> options > > > True, but permitting root login is clearly one that is a lot more > > important/relevant than all the others. Currently, the typical user will naively > > enable openssh, then try to ssh into the device, and fail... > > Correct. It will also fail for dropbear as the root user by default does > not have a password set. > > > >> So all in all, this kind of policy tweaks are better done in a post > >> build script. > > > In the few projects where I've seen openssh used, it was always with a custom > > config file. Otherwise, there's not much reason to use openssh instead of > > dropbear I guess. > > Indeed. I always use dropbear as well. One reason for using openssh instead of dropbear without a custom config would be for sftp support. > > -- > Bye, Peter Korsgaard > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
On 20/03/2019 10:05, James Hilliard wrote: > On Wed, Mar 20, 2019 at 2:58 AM Peter Korsgaard <peter@korsgaard.com> wrote: >> >>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: [snip] >> > In the few projects where I've seen openssh used, it was always with a custom >> > config file. Otherwise, there's not much reason to use openssh instead of >> > dropbear I guess. >> >> Indeed. I always use dropbear as well. > One reason for using openssh instead of dropbear without a custom > config would be > for sftp support. ... which is why we have gesftpserver :-) Regards, Arnout
James, All, On 2019-03-20 03:05 -0600, James Hilliard spake thusly: > One reason for using openssh instead of dropbear without a custom > config would be > for sftp support. So we have gesftpserver that can be used with dropbear to provide sftp, and AFAICS, that works just out of the box. I don't understand what you mean by "without a custom config". Regards, Yann E. MORIN.
On Wed, Mar 20, 2019 at 3:27 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > James, All, > > On 2019-03-20 03:05 -0600, James Hilliard spake thusly: > > One reason for using openssh instead of dropbear without a custom > > config would be > > for sftp support. > > So we have gesftpserver that can be used with dropbear to provide sftp, > and AFAICS, that works just out of the box. Huh, I've never heard of that before and somehow didn't come across it when I searched for a way to use sftp with dropbear, will try it out. > > I don't understand what you mean by "without a custom config". Oh, that was in reference to the comment above yours. > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------'
> From: "Arnout Vandecappelle" <arnout@mind.be> > To: "Peter Korsgaard" <peter@korsgaard.com>, "Esben Haabendal" <esben.haabendal@gmail.com> > Cc: "Esben Haabendal" <esben@haabendal.dk>, "buildroot" <buildroot@buildroot.org> > Sent: Terça-feira, 19 de março de 2019 21:23:42 > Subject: Re: [Buildroot] [RFC] openssh: add option to allow login as root > On 19/03/2019 23:42, Peter Korsgaard wrote: >>>>>>> "Esben" == Esben Haabendal <esben.haabendal@gmail.com> writes: >> >> > From: Esben Haabendal <esben@haabendal.dk> >> > What do you think. Is this kind of micro-management of a configuration >> > file something that I should keep out of tree? >> >> We discussed it tonight on IRC and didn't really get to a good compromise. >> >> On one hand, we prefer to stick with upstream defaults (especially when >> security is involved) > > This patch doesn't change the defaults. > >> , but it is true that dropbear allows root logins >> by default. > > It's not nice that the default for dropbear and ssh is different, but that has > little to do with deciding if this kind of configurability is relevant or not. > >> We prefer to not add configuration options for these kind of >> detailed policy decisions, > > *That* is the crux of the matter. We normally only have configurability of > compile-time options, and assume that anything else is handled in post-build > scripts. The (only?) exception to that principle is the system menu. > > So *maybe* something global in the system menu could work, and then dropbear > and openssh and whatnot would do whatever is needed to permit/disallow root > login for that particular package. But I'm not exactly ecstatic about that > option. A global option to allow login as root via SSH regardless which ssh server is chosen looks like a nice feature to me.
diff --git a/package/openssh/Config.in b/package/openssh/Config.in index 683a9c0e5191..bc4f40efa3de 100644 --- a/package/openssh/Config.in +++ b/package/openssh/Config.in @@ -9,3 +9,13 @@ config BR2_PACKAGE_OPENSSH friends. http://www.openssh.com/ + +if BR2_PACKAGE_OPENSSH + +config BR2_PACKAGE_OPENSSH_PERMIT_ROOT_LOGIN + bool "Allow SSH root login" + help + Modify SSH server configuration to allow login as root. + Warning: This might not be a good idea. Use at own risk! + +endif diff --git a/package/openssh/openssh.mk b/package/openssh/openssh.mk index 4fef5caedb01..8d1c153a8752 100644 --- a/package/openssh/openssh.mk +++ b/package/openssh/openssh.mk @@ -88,4 +88,11 @@ endef OPENSSH_POST_INSTALL_TARGET_HOOKS += OPENSSH_INSTALL_SSH_COPY_ID +ifeq ($(BR2_PACKAGE_OPENSSH_PERMIT_ROOT_LOGIN),y) +define OPENSSH_INSTALL_PERMIT_ROOT_LOGIN + $(SED) 's/\#PermitRootLogin prohibit-password/PermitRootLogin yes/' $(TARGET_DIR)/etc/ssh/sshd_config +endef +OPENSSH_POST_INSTALL_TARGET_HOOKS += OPENSSH_INSTALL_PERMIT_ROOT_LOGIN +endif + $(eval $(autotools-package))
From: Esben Haabendal <esben@haabendal.dk> What do you think. Is this kind of micro-management of a configuration file something that I should keep out of tree? /Esben --- package/openssh/Config.in | 10 ++++++++++ package/openssh/openssh.mk | 7 +++++++ 2 files changed, 17 insertions(+)