Re: Configure command shell idle timeout default?

Mark Hatle

On 8/3/21 6:46 PM, Joseph Reynolds wrote:
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:
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. timeoutInSeconds

- 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.
To me the above means that you must have a way to do this, and it must be
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).

Technical implementation:

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.)
It's my understanding that this is typically done via PAM and standard

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.
In the past, when I've worked on this stuff, we did timeout stuff in a
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
- 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.
PAM can forcably set the user's environment on login. Which can be used to
influence the other actions.

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.
Yes, this is exactly why we used screen in the design I worked on. It ensured
the timeout, no matter what the running application was.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per preprocessor
2. When the server starts via argument `-I 0`, and note SSH server
started by: where
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.
This is the key, the default should continue to be no timeout. HOWEVER, as
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

I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
I think what I'd like to see from the Yocto Project perspective is to document
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).
Agreed, I'm certainly interested in that.
I've tried to push into, 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 trying
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!
For my own products, I need to ensure that root logins are NOT allowed, no
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
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.
We turned off debug_tweaks in the image config, which ensured that no default
password was set.

EXTRA_IMAGE_FEATURES_remove = "debug-tweaks"

We then used the extra_user_parmas to add a user:

EXTRA_USER_PARAMS = "useradd -p '' petalinux;passwd-expire petalinux;usermod -a
-G audio petalinux;usermod -a -G video petalinux"

The above adds the user 'petalinux' with NO password required to login, we then
immediately expire the password (causing the first login to require a password).
The usermods give that user access to a few hardware resources that otherwise
you may need root for.

The who items above, along with the standard OpenSSH configuration preventing
password-less logins, will ensure that the only a local console login is
permitted. Since root doesn't have a password (:*: disabled password by
default), the user is forced to login to the account we've provided. Then on
first login forced to change their password.

Additionally we added a function to enable sudo access:

USERADDEXTENSION_append = " pln-useradd-suders"

This is what lets that user sudo, if I was doing a more secure system we
probably would have restricted it to specific sudo applications.

The code for that function is:

I've seen systems that do something like the above but randomize the account
name, and then present it during console boot. I'm not sure if that really
makes anything more secure. Not setting ANY default password, and requiring the
console login may not work on my systems without consoles -- but for us it
worked well since this device was plug it in, attach to a monitor, and add a


Thank you,
- Joseph




Join to automatically receive all group messages.