Skip to content

Provisioning based on (SSH) environment variables #23

@brainstorm

Description

@brainstorm

Many SSH clients pass environment variables to the server for many purposes, i.e: X11 forwarding. On the IC side, most of those variables can be optionally persisted via a suitable K-V abstraction over the flash, i.e:

https://crates.io/crates/sequential-storage
https://crates.io/crates/ekv

or a higher level (and secure) abstraction like: OpenDevicePartnership/embedded-services#267

NOTE: Check esp-rs/esp-hal#3426 status as well before implementing too.

Exploit this fact to simplify provisioning of new SSH Stamps. Environment variables will be used to, among other functions:

  1. Set the UART bridge parameters such as BAUD speed, stop bits.
  2. UART physical pins mapped to the microcontroller pin MUX, etc...
  3. Pass the password and store it for subsequent sessions, disallowing un-authenticated password changes after first initialization.
  4. Pass the private key(s) and/or trigger in-device private key generation.
  5. In the future, pass settings such as CAN IDs, I2C address, etc... if we can reasonably bridge other protocols than just UART (challenges: timing restrictions, buffering, etc...).

This approach avoids having complicated at-flashing-time deployment(s) of sensitive cryptographic material and hopefully simplifies provisioning UX: a device can be shipped in "virgin but ready to use" state and be NON INTERACTIVELY provisioned via SSH env vars (think ansible).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions