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.

One clear goal was to have all the complexity on the server-side, and be able to construct a minimal client.

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.

FAQ

Why not use Age?

I like age a lot, and it's ability to use more ssh key types is certainly a winner feature. However, one goal here is to be able to construct a client with minimal dependencies, and that speaks in favor of the current solution.

Using just RSA keys, you can construct a client using only the following tools:

• base64
• openssl
• ssh

This means that you can create a client using just a shell script.