KEYPER: Manage SSH Key Based Authentication

Keyper is an SSH Key Based Authentication Manager

Why Keyper?

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.

Is Keyper opensource?

Not yet. However, we are working to get it open-sourced under GPLv2 (pending permission from our corporate overlords).
Yes! We Opensourced Keyper under GPLv3 license. The source repositories are located at keyper-docker and keyper.
Following components of keyper are opensourced:

  • keyper REST API
  • keyper docker image builder
  • All artifacts related to openldap schema

The above stack can be administored using curl CLI.

The web based administration console for Keyper has not been opensourced.

The above arrangement should satisfy needs of most of our users as smaller commercial customers can continue to use the web based admin console bundled with docker image upto 20 servers. After which they have option to purchase license.

Where can I get Keyper?

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

Where is the documentation?

All documentation is located here

Do you have a Demo/Sandbox for Keyper?

Yes we do. We have a demo system running on And also 4 containers running SSH that can be used for testing. Here are credentials to access the web-console:

User IDPassword

In addition, you can test following containers running SSH using above user ids after you add your SSH public key to the web-console:

ServerSSH Port

So, if you want to access server as user frank, you need to add your SSH public key (typically ~/.ssh/ or ~/.ssh/ to user frank and then connect using ssh:

$ ssh -l frank -p 4022

Any issues drop us a line at

This demo system is limited and only allows you to upload/delete SSH public keys (Keyper User Role). You do not have admin access to add/modify users/hosts/groups (Keyper Admin Role). To see admin features in action, we suggest that you download and run the docker image either using docker or podman on your Linux system.

You are sharing these demo systems with others. Please be respectful of others. We delete all uploaded keys every night.

I have a question which is not answered here.

Send your question to and we’ll try to address it.

What is under the hood?

Keyper is published as a Docker container which can also be run using podman. The stack include:

  • Alpine Linux
  • OpenLDAP acting as a directory that stores all users, SSH Public Keys, and rules
  • Python Flask REST API
  • VueJS frontend app running on Nginx
  • All the above services are managed using runit

What SSH servers are supported by Keyper?

Any Linux server running OpenSSH 6.8 or newer should be fine. An SSH server that supports AuthorizedKeysCommand is needed.

What is Podman?

Per podman projetct’s website: “Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images. Podman provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. Most users can simply alias Docker to Podman (alias docker=podman) without any problems.”
Best thing we liked about podman is that one need not be root to run a container. It comes bundled with RHEL (or any RHEL based distro) by default. If you do not have it install it using yum:

# yum install podman

How to persist OpenLDAP data on restart?

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:

What is the purpose of hostname as a parameter?

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 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
25b2869f1a71 dbsentry/keyper "/container/tools/run" 21 hours ago Up 21 hours>80/tcp,>389/tcp,>443/tcp,>636/tcp peaceful_lewin
66d33bbdd32c jenkinsci/blueocean "/sbin/tini -- /usr/…" 13 days ago Up 13 days>50000/tcp,>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
/ # 

What environment variables can I set?

Following environment variables can be set while starting the container:

Environment VariableDescriptionDefault
LDAP_PORTldap bind port389
LDAPS_PORTldaps bind port636
LDAP_ORGANIZATION_NAMEName of the OrganizationExample Inc.
LDAP_LDAP_ADMIN_PASSWORDAdmin password on LDAPsuperdupersecret
LDAP_TLS_CRT_FILENAMECert File Nameserver.crt
LDAP_TLS_KEY_FILENAMECert Key File Nameserver.key
LDAP_TLS_DH_PARAM_FILENAMEDH Param File Namedhparam.pem
FLASK_CONFIGFlask Config (dev/prod)prod
HOSTNAMEHostname{docker generated}

How can I see Debug messages for the REST API?

Running a container with FLASK_CONFIG=dev would force Flask REST API to run in debug mode.

Where is the auditlog for OpenLDAP located

/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

How can I backup Keyper?

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.

How do I use a real SSL certificate with Keyper?

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.