On 8/3/21 1:54 PM, Mark Hatle wrote:
On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:To me the above means that you must have a way to do this, and it must be
Yocto security community,
Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?
I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
- OWASP suggests idle timeouts of 15-30 minutes.
configured as such... The Yocto Project doesn't care as much about the 'must be
configured as much', but definitely we should care about the 'you CAN configure
it as such, without impacting users who don't want a timeout.'
Thanks. I understand and accept that Yocto will continue without any SSH or shell session idle timeouts.
I will pursue this configuration change for my downstream project (OpenBMC).
It's my understanding that this is typically done via PAM and standard
I understand the timeout can be implemented either in the SSH session or
in the underlying application:
The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout. (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)
In the past, when I've worked on this stuff, we did timeout stuff in a
The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.
combination of 'screen', and ssh settings. Login would run through screen with
a timeout defined.
Screen could be set with a specific idle that required credentials, and then
bash (or other shells) would be set with a specific timeout as well. This would
ensure that the screen locks after a specific amount of time, such as 15
minutes. And the shell (Assuming it's back) will actually exit after a specific
Thanks. I've got that idle timeouts can be provided in one of several ways:
- Provided by the underlying application itself (such as the bash TMOUT variable).
- Provided by the SSH server, per client connection.
- Provided by a tool such as "screen" which runs between the client and the application.
I'm not aware of any way for Linux-PAM to provide an idle timeout.
For my use case, my application may not have an idle timeout function, and if I switch to openSSH which does not have an idle timeout function, I may need to use something like "screen" to provide this function.
This is the key, the default should continue to be no timeout. HOWEVER, as
The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
2. When the server starts via argument `-I 0`, and note SSH server
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).
I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default. I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.
Richard mentions below, there needs to be a documented approach for specifying
the timeouts. My opinion is that these should be configurable via root owned
configuration files to ensure settings can't be "changed" without appropriate
Agreed, I'm certainly interested in that.
I've added this question to the OpenBMC security working group agenda.I think what I'd like to see from the Yocto Project perspective is to document
Next meeting Wednesday August 4. Access via
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).
I've tried to push https://github.com/openbmc/openbmc/wiki/Configuration-guide
, but there was not enough interest. And yet questions come up regularly in the project's email list which can be answered by providing a link to the configuration guide. So I know a configuration guide is useful.
I know you mentioned some work related to changing passwords too and tryingFor my own products, I need to ensure that root logins are NOT allowed, no
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
default passwords are present and on first _CONSOLE_ login, the user to prompted
to set a password. (We do set a default user account, that has been given sudo
access.) Remote login's are not allowed until that has been done. (This is
already implemented and actually easy to accomplish. If there is additional
document requested about how to do this, let me know and I can share the steps
we do for the docs.)
I am still trying to move OpenBMC from root login to an admin account. This is not yet accomplished because of the difficulty in changing this kind of configuration, and I believe projects downstream from OpenBMC have already shut off root access. In any case, the configuration setting to do so are clearly identified. For example, you can see from the OpenBMC configuration guide that "root_user_mgmt" in https://github.com/openbmc/phosphor-user-manager/blob/master/configure.ac
configures OE-core parameters along with some OpenBMC-specific code to enable or disable root logins.
I am interested in your method to ensure an initial password is set before allowing additional accesses.