You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alternatively, manage a private key that works with miniconfig for a "miniadmin" user that is unique to miniconfig and which can be shared with team members. This would allow miniconfig to remain static as well as reducing its size, since it would only need to contain one public key. Given the extremely low attack surface of the time miniconfig is loaded on the switches, it might even be worth considering embedding this private key in the switch_config_loader script and have it auto-add it to the running user's .ssh/ directory and reference it when attaching to the switch to load a config on top of miniconfig.
This approach would require some additional thought and considerations, but I wanted to get it written down first for wider discussion.
Given the extremely low attack surface of the time miniconfig is loaded on the switches, it might even be worth considering embedding this private key in the switch_config_loader script and have it auto-add it to the running user's .ssh/ directory and reference it when attaching to the switch to load a config on top of miniconfig.
Putting this into a nix devShell we can wrap ssh flags (-i, etc.) so you wouldnt even need to copy the key into your ~/.ssh
Description
Currently miniconfig is static and doesn't track current SSH keys.
Acceptance Criteria
Have a script which builds an appropriate minimal config for flashing containing all current SSH keys.
The text was updated successfully, but these errors were encountered: