Keyper is an SSH Key Based Authentication Manager. It standardizes and centralizes the storage of SSH public keys for all Linux users in your organization saving significant time and effort it takes to manage SSH public keys on each Linux Server. Keyper is a lightweight container taking less than 100MB. It is launched either using Docker or Podman. You can be up and running within minutes instead of days.
Run Keyper docker image using docker cli:
$ docker run -p 8080:80 -p 8443:443 --hostname <hostname> --env FLASK_CONFIG=prod -it dbsentry/keyper
Run Keyper docker image using podman cli:
$ podman run -p 8080:80 -p 8443:443 --hostname <hostname> --env FLASK_CONFIG=prod -it docker.io/dbsentry/keyper
Either command starts a new container with Keyper processes (OpenLDAP, Gunicorn, Nginx) running inside.
Customary 5 min installation Demo
Keyper is an SSH Key Based Authentication Manager
We, as system administrators and developers, regularly use OpenSSH’s public key authentication (aka password-less login) on Linux servers. The mechanism works based on public-key cryptography. One adds his/her RSA/DSA key to the authorized_keys file on the server. The user with the corresponding private key can login without a password. It works great until the number of servers starts to grow. It becomes a pain to manage the authorized_keys file on all the servers. Account revocation becomes a pain as well. Keyper aims to centralize all such SSH Public Keys within an organization. With Keyper, one can force key rotation, easily revoke keys, and centrally lock accounts.
Not yet. However, we are working to get it open-sourced under GPLv2 (pending permission from our corporate overlords).
Keyper can be downloaded from the docker registry either using docker or podman.
Thanks in advance. We love suggestions/bug reports. Please drop us a line at firstname.lastname@example.org
All documentation is located here
Yes we do. We have a demo system running on https://sprout.dbsentry.com. And also 4 containers running SSH that can be used for testing. Drop us a line at email@example.com and we’ll send you credentials.
Send your question to firstname.lastname@example.org and we’ll try to address it.
Keyper is published as a Docker container which can also be run using podman. The stack include:
Any Linux server running OpenSSH 6.8 or newer should be fine. An SSH server that supports AuthorizedKeysCommand is needed.
By default, Keyper creates OpenLDAP database within container under /var/lib/openldap/openldap-data and /etc/openldap/slapd.d. For data to persist after a restart, we need to present local docker volumes as a parameter. Something like this:
$ docker volume create slapd.d $ docker volume create openldap-data $ docker run -p 80:80 -p 443:443 -p 389:389 -p 636:636 --hostname <hostname> --mount source=slapd.d,target=/etc/openldap/slapd.d --mount source=openldap-data,target=/var/lib/openldap/openldap-data -it dbsentry/keyper
For more information about docker data volume, please refer to:
Keyper uses this hostname to generate a self-signed certificate. OpenLDAP and Nginx use this certificate for secure communication. Also, this hostname gets embedded in the auth.sh script which you need to download and deploy on each Linux server.
Great. First find the container id of the running container, and then use “docker exec” to connect. Something like this:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 25b2869f1a71 dbsentry/keyper "/container/tools/run" 21 hours ago Up 21 hours 0.0.0.0:8080->80/tcp, 0.0.0.0:2389->389/tcp, 0.0.0.0:8443->443/tcp, 0.0.0.0:2636->636/tcp peaceful_lewin 66d33bbdd32c jenkinsci/blueocean "/sbin/tini -- /usr/…" 13 days ago Up 13 days 0.0.0.0:50000->50000/tcp, 0.0.0.0:8000->8080/tcp jenkins-blueocean $ docker exec -it 25b2869f1a71 /bin/sh / # ls bin dev home media opt root sbin sys usr container etc lib mnt proc run srv tmp var / #
Following environment variables can be set while starting the container:
|LDAP_PORT||ldap bind port||389|
|LDAPS_PORT||ldaps bind port||636|
|LDAP_ORGANIZATION_NAME||Name of the Organization||Example Inc.|
|LDAP_LDAP_ADMIN_PASSWORD||Admin password on LDAP||superdupersecret|
|LDAP_TLS_CA_CRT_FILENAME||CA Cert File Name||ca.crt|
|LDAP_TLS_CRT_FILENAME||Cert File Name||server.crt|
|LDAP_TLS_KEY_FILENAME||Cert Key File Name||server.key|
|LDAP_TLS_DH_PARAM_FILENAME||DH Param File Name||dhparam.pem|
|LDAP_TLS_CIPHER_SUITE||Default Cipher Suite||TLSv1.2:HIGH:!aNULL:!eNULL|
|FLASK_CONFIG||Flask Config (dev/prod)||prod|
Running a container with FLASK_CONFIG=dev would force Flask REST API to run in debug mode.
/var/log/openldap/auditlog.ldif. It may be a better idea to create docker volume for /var/log and mount it in the container to persist logs
As far as you have a backup for the OpenLDAP database you are good to go. For the rest, as far as you specify the same cli params things should work fine.
The certificate is used by OpenLDAP and Nginx. You can set custom certificate at run time by mounting a directory containing those files to /container/service/nginx/assets/certs and adjust their name per the environment variables defined above.