Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# b7dddbc6 27-Mar-2024 Andrew Geissler <geissonator@yahoo.com>

obmc-console-ssh@.service: add ECDSA and ED25519 keys

With RSA-SHA1 being deprecated, have our dropbear server also support
ECDSA and ED25519 keys.

The key generation and support within our standar

obmc-console-ssh@.service: add ECDSA and ED25519 keys

With RSA-SHA1 being deprecated, have our dropbear server also support
ECDSA and ED25519 keys.

The key generation and support within our standard ssh port 22 was added
via commit [1].

This commit adds support for our virtual console ports that come in via
ssh.

The service files have a somewhat unfortunately named variable,
DROPBEAR_RSAKEY_DIR, which assumed dropbear was only going to support
RSA keys. As this commit shows, dropbear supports multiple key types and
the directory, /etc/dropbear/, has no limitations on the type of key
that can go in that directory. Initially, we changed this variable name
to DROPBEAR_KEY_DIR but upon further investigation we saw that this
naming convention was utilized heavily in the dropbear recipes. To keep
things consistent with dropbear, we left it as DROPBEAR_RSAKEY_DIR even
though other key types will be stored in that directory.

Tested:
- Confirmed port 2200 and 2201 dropbear services loaded new RSA keys
(via 'ps' command) on p10bmc machine
- Confirmed when an ssh was done to port 2200, it connected, properly
and listed the following as supported via "ssh -vv":
host key algorithms: ssh-ed25519,ecdsa-sha2-nistp384,rsa-sha2-256

[1]: https://gerrit.openbmc.org/c/openbmc/openbmc/+/70265

Change-Id: I76dd742654a67645d12856ae8fd15dfe71876b9d
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

show more ...


Revision tags: v1.1.0
# 533f9702 09-Mar-2023 Ninad Palsule <ninadpalsule@us.ibm.com>

Changes for new pre-defined usergroup hostconsole

The new pre-defined usergroup named "hostconsole" is added to
differentiate access between host console and manager console.
The only users allowed

Changes for new pre-defined usergroup hostconsole

The new pre-defined usergroup named "hostconsole" is added to
differentiate access between host console and manager console.
The only users allowed to interact with host console are part of the
"hostconsole" group.

Note: The changes are spread across multiple repositories listed under
"Related commits:"

The obmc-console changes to incorporate new group are as follows:
- Remove dependency on dropbear.default file by adding new default file
dropbear.env for obmc-console. This file is required for obmc
services. This file is added in obmc-console-ssh@.service.in and
use-socket.conf
- In future we can add file /etc/obmc-console/dropbear.%i.env for port
specific configuration.

Tested:
Loaded on system and qemu eumulator. Made sure that the new file
contents are reflected on the system.

Related commits:
docs: https://gerrit.openbmc.org/c/openbmc/docs/+/60968
phosphor-user-manager: https://gerrit.openbmc.org/c/openbmc/phosphor-user-manager/+/61583
openbmc: https://gerrit.openbmc.org/c/openbmc/openbmc/+/61582
obmc-console: https://gerrit.openbmc.org/c/openbmc/obmc-console/+/61581
bmcweb: https://gerrit.openbmc.org/c/openbmc/bmcweb/+/61580

Change-Id: Id080d0cf1c8dea7c383bc040c988dae2b4a09800
Signed-off-by: Ninad Palsule <ninadpalsule@us.ibm.com>

show more ...


# 9836e2b3 10-Feb-2020 Andrew Jeffery <andrew@aj.id.au>

conf: Ship default configuration and systemd units

Two configurations are supported:

1. A socket-activated, single-port client service arrangement, and
2. A port-templated clien

conf: Ship default configuration and systemd units

Two configurations are supported:

1. A socket-activated, single-port client service arrangement, and
2. A port-templated client service

systemd's template-unit constraints prevent us from mapping ports to a
daemon configuration for the socket-activated case. To support multiple
concurrent console servers we have to revert to a standard daemon
arrangement where dropbear binds, listens and accepts its own
connections. This brings with it immediate memory overhead of running
dropbear before connections are received. As such configuration 2 is
opt-in as there are very few systems that require it.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ifbcac1b1ca75ab3ff08c73855d7ed2ebabc27c0a

show more ...