| commit | b7dddbc63e601298474dee68ea4c0cc25b865461 | [log] [tgz] |
|---|---|---|
| author | Andrew Geissler <geissonator@yahoo.com> | Wed Mar 27 16:13:21 2024 -0500 |
| committer | Andrew Jeffery <andrew@codeconstruct.com.au> | Thu Apr 18 00:53:48 2024 +0000 |
| tree | 2030f7ded94cb1d1ef8fe25c6322e0b21c61d4e9 | |
| parent | 7f2bfb9b9f760f9599ce24e772e78f9ade43cc0f [diff] |
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>
To build this project, run the following shell commands:
meson setup build meson compile -C build
To test:
meson test -C build
Running the server requires a serial port (e.g. /dev/ttyS0):
touch obmc-console.conf ./obmc-console-server --config obmc-console.conf ttyS0
To connect to the server, simply run the client:
./obmc-console-client
To disconnect the client, use the standard ~. combination.
This shows how the host UART connection is abstracted within the BMC as a Unix domain socket.
+---------------------------------------------------------------------------------------------+
| |
| obmc-console-client unix domain socket obmc-console-server |
| |
| +----------------------+ +------------------------+ |
| | client.2200.conf | +---------------------+ | server.ttyVUART0.conf | |
+---+--+ +----------------------+ | | +------------------------+ +--------+-------+
Network | 2200 +--> +->+ @obmc-console.host0 +<-+ <--+ /dev/ttyVUART0 | UARTs
+---+--+ | console-id = "host0" | | | | console-id = "host0" | +--------+-------+
| | | +---------------------+ | | |
| +----------------------+ +------------------------+ |
| |
| |
| |
+---------------------------------------------------------------------------------------------+
This supports multiple independent consoles. The console-id is a unique portion for the unix domain socket created by the obmc-console-server instance. The server needs to know this because it needs to know what to name the pipe; the client needs to know it as it needs to form the abstract socket name to which to connect.