Re: Configure command shell idle timeout default?

Mark Hatle

On 8/3/21 10:05 AM, Joseph Reynolds 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.

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

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.

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.

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

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!
Mea culpa!  I have a two unresolved issues:
- Proposal to write an "initial/administratively expired password" into
/etc/shadow -
Password expire is already merged:


commit 834ef343b3694ccc4d44999771d49fb316f242e0
Author: Joseph Reynolds <joseph-reynolds@...>
Date: Tue Nov 10 11:56:42 2020 +0800

add new extrausers command passwd-expire

This enhances extrausers with a new passwd-expire command that causes
a local user's password to be expired as if the `passwd --expire`
command was run, so the password needs to be changed on initial login.

Example: EXTRA_USERS_PARAMS += " useradd ... USER; passwd-expire USER;"

Tested: on useradd accounts
When configured with Linux-PAM, console login prompts for and can
successfully change the password. OpenSSH server works. Dropbear
SSH server notes the password must be changed but does not offer a
password change dialog and rejects the login request.

(From OE-Core rev: 1bdcfa4b0d378947a6759fb91872a4edc9a42622)

Signed-off-by: Joseph Reynolds <joseph-reynolds@...>
Signed-off-by: Kai Kang <kai.kang@...>
Signed-off-by: Richard Purdie <richard.purdie@...>

We use this in our stuff to expire the user's password already.

- Proposal to fixup PACKAGECONFIG to avoid pulling in
Python3 -

I believe the proposals are well defined and coded up.  My inhibitors
are finding time and rounding out my skillset.  Maybe I can find a
minion to do these for me.  :-)

- Joseph



Join to automatically receive all group messages.