Keyper

SSH Key and Certificate Manager

Download Source

Latest release

KEYPER

Docker Pulls

Keyper is an Open Source SSH Key and Certificate-Based Authentication Manager. Keyper acts as an SSH Certificate Authority (CA). It standardizes and centralizes the storage of SSH public keys and SSH Certificates for all Linux users in your organization and saves significant time and effort it takes to manage SSH keys and certificates on each Linux Server. Keyper also maintains an active Key Revocation List, which prevents the use of Key/Cert once revoked. Keyper is a lightweight container taking less than 100MB. It supports both using Docker and Podman. You can be up and running within minutes instead of days.

Features include:

  • Public key storage
  • SSH CA
  • Certificate Signing and Storage
  • Certificate Expiration
  • Public Key Expiration
  • Key Revocation List (KRL)
  • Forced Key rotation
  • Streamlined provision or de-provisioning of users
  • Segmentation of Servers using groups
  • Policy definition to restrict user’s access to the server(s)
  • Centralized user account lockout
  • Docker container

Quickstart

Run Keyper docker image using docker cli:

$ docker run                    \
        -p 8080:80              \
        -p 8443:443             \
        --hostname <hostname>   \
        -it dbsentry/keyper

Run Keyper docker image using podman cli:

$ podman run  
         -p 8080:80                 \
         -p 8443:443                \
         --hostname <hostname>      \
         -it quay.io/dbsentry/keyper

Either command starts a new container with Keyper processes (OpenLDAP, Gunicorn, Nginx) running inside.

The above commands are for demo only and start a new container with OpenLDAP server storing data within the container. That means on re-start, data would not persist. If you want data persistence, start the container with appropriate command line parameters. Refer to the documentation.
By default, this image creates an LDAP server for the company Example Inc and the domain keyper.example.org. By default, all passwords are set to superdupersecret. All the default settings can be changed by passing parameters to the docker/podman command line or using a parameter config file.

Customary 5 min installation Demo

Pricing

Personal

Free for personal use.                                                                                                                                                                        ‌

Commercial

Free for upto 20 servers and 5 users. $1/month for additional servers and users. Contact sales@dbsentry.com

FAQ

Table of Contents

General

What is Keyper?

Keyper is an SSH Key and Certificate-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 or Certificate-based authentication (more secure). 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.

Why Certificate-based authentication

SSH Key-based authentication does a great job. Certificate-based authentication eliminates a few limitations associated with Key-based authentication. When using certificates, both clients and servers use certificates signed by a trusted third party (e.g. Keyper). Certificates take care of long time known issue such as Trust-on-First-Use (TOFU). Instead of X.509 format, SSH uses its own, simpler, certificate format.

Why should one use Keyper for certificate-based authentication

There is one little inconvenience with certificates, and that is a user cannot sign their keys themselves as they do not have access to CA’s private key. A process must be put in place to sign the keys. Once the administrator sets up a user in the Keyper system, s/he can upload keys to be signed by the CA. Keyper system generates the certificate on the fly based on pre-defined rules (like duration of the certificate, and what servers/principals any given user has access to).

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.
The following components of keyper are open-source:

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

The above stack can be administered using curl CLI.

The web-based administration console for Keyper has not been open-sourced.

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

Where can I get Keyper?

Keyper can be downloaded from the docker registry either using docker or podman.

I have a question/suggestion/need to report a bug. How can I contact you?

Thanks in advance. We love suggestions/bug reports. Please drop us a line at support@dbsentry.com

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 https://sprout.dbsentry.com plus four containers running SSH for testing. Here are credentials to access the web console:

User IDPassword
alicekeyper
bobkeyper
carolkeyper
erinkeyper
frankkeyper
gracekeyper

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

ServerSSH Port
mavrix2.dbsentry.com2022
mavrix3.dbsentry.com3022
mavrix4.dbsentry.com4022
mavrix5.dbsentry.com5022

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

$ ssh -l frank -p 4022 mavrix4.dbsentry.com

Any issues, drop us a line at support@dbsentry.com.

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 that is not answered.

Send your question to support@dbsentry.com, and we’ll try to address it. You can also hang out with us on Discord

Technical

What is under the hood?

Keyper is a Docker container, which can also be run using podman. The stack includes:

  • 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 version of SSH Keyper supports?

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 project’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.”
The 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:

https://docs.docker.com/engine/tutorials/dockervolumes/

What is the purpose of a 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 auth.sh script, which you need to download and deploy on each Linux server.

I want to connect to Keyper on a different terminal to see its inside?

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

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_DOMAINLDAP Domainkeyper.example.org
LDAP_LDAP_ADMIN_PASSWORDAdmin password on LDAPsuperdupersecret
LDAP_TLS_CA_CRT_FILENAMECA Cert File Nameca.crt
LDAP_TLS_CRT_FILENAMECert File Nameserver.crt
LDAP_TLS_KEY_FILENAMECert Key File Nameserver.key
LDAP_TLS_DH_PARAM_FILENAMEDH Param File Namedhparam.pem
LDAP_TLS_CIPHER_SUITEDefault Cipher SuiteTLSv1.2:HIGH:!aNULL:!eNULL
FLASK_CONFIGFlask Config (dev/prod)prod
HOSTNAMEHostname{docker generated}
NGINX_UIDlinux nginx user uid10080
NGINX_UIDlinux nginx user uid10080
SSH_CA_HOST_KEYCA Host Keyca_host_key
SSH_CA_USER_KEYCA USER Keyca_user_key

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 X.509 SSL certificate with Keyper?

OpenLDAP and Nginx require the X.509 certificate. 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.

What is SSH Key Revocation List (KRL)?

A Key Revocation List (KRL) is a list identifying the revoked Keys and Certificates. In Keyper, a Key or Certificate once deleted, gets added to the KRL. Both Key-based and Certificate-based SSH authentication on Keyper uses KRL verification as the first step during authentication and prevents the use of revoked Keys/Certificates.

How can I access the KRL File?

The KRL file is located on the running container under /etc/sshca/ca_krl. It can also be downloaded using API call https://servername/api/krlca

Subscribe

Subscribe to receive Keyper's Announcements

* indicates required

Contact