60 lines
2.2 KiB
Markdown
60 lines
2.2 KiB
Markdown
# Sshecret - Openssh based secrets management
|
|
|
|
## Motivation
|
|
|
|
There are many approaches to managing secrets for services, but a lot of these
|
|
either assume you have one of the industry-standard systems like hashicorp vault to manage them centrally.
|
|
|
|
For enthusiasts or homelabbers this becomes overkill quickly, and end up
|
|
consuming a lot more time and energy than what feels justified.
|
|
|
|
This system has been created to provide a centralized solution that works well-enough.
|
|
|
|
## Components
|
|
|
|
This system has been designed with modularity and extensibility in mind. It has the following building blocks:
|
|
|
|
- Password database
|
|
- Password input handler
|
|
- Encryption and key management
|
|
- Client secret storage backend
|
|
- Custom ssh server
|
|
|
|
### Password database
|
|
Currently a single password database is implemented: Keepass.
|
|
|
|
Sshecret can create a database, and store your secrets in it.
|
|
|
|
It only uses a master password for protection, so you are responsible for
|
|
securing the password database file. In theory, the password database file can
|
|
be disconnected after encrypting the passwords for the clients, and these two
|
|
components may be disconnected.
|
|
|
|
### Password input handler
|
|
Passwords can be randomly generated, they can be read from stdin, or from environment variables.
|
|
|
|
Other methods can be implemented in the future.
|
|
|
|
### Client secret storage backend
|
|
So far only a simple JSON file based backend has been implemented. It stores one file per client.
|
|
The interface is flexible, and can be extended to databases or anything else really.
|
|
|
|
### Custom SSH server
|
|
A custom SSH based on paramiko is included. This is how the clients receive the encrypted password.
|
|
The client must send a single command over the SSH session equal to the name of the secret.
|
|
|
|
If permitted to access the secret, it will returned encrypted with the client RSA public key of the client, encoded as base64.
|
|
|
|
This allows the client to decrypt and get the clear text value easily.
|
|
|
|
## Usage
|
|
|
|
# Next step
|
|
## Rewrite encryption to use age
|
|
The RSA implementation works alright, but requires some work on the client side converting back to a readable format.
|
|
Age seem better suited, as it can also use ed25519 keys.
|
|
|
|
|
|
## Dedicated client?
|
|
If `age` works out, it may be entirely unnecessary to have a dedicated client. Who knows...
|