[Buildroot] [RFC] openssh: add option to allow login as root

[Buildroot] [RFC] openssh: add option to allow login as root

[Esben Haabendal]

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(+)

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))
-- 
2.21.0

[Buildroot] [RFC] openssh: add option to allow login as root

[Grant Edwards]

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.

-- 
Grant Edwards               grant.b.edwards        Yow! I want to so HAPPY,
                                  at               the VEINS in my neck STAND
                              gmail.com            OUT!!

[Buildroot] [RFC] openssh: add option to allow login as root

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [RFC] openssh: add option to allow login as root

[Arnout Vandecappelle]

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

[Buildroot] [RFC] openssh: add option to allow login as root

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [RFC] openssh: add option to allow login as root

[James Hilliard]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [RFC] openssh: add option to allow login as root

[Arnout Vandecappelle]

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

[Buildroot] [RFC] openssh: add option to allow login as root

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] openssh: add option to allow login as root

[James Hilliard]

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.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] openssh: add option to allow login as root

[Carlos Santos]

> 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.

-- 
Carlos Santos (Casantos) - DATACOM, P&D