# 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...