Keeto is a module for OpenSSH that enables profile-based administration of access permissions in a central LDAP aware Directory Service, adds support for X.509 certificates and handles the distribution of OpenSSH key material in an automated and secure manner.
The fundamental idea behind is to leverage existing infrastructure usually found in larger enterprises for managing access to OpenSSH servers comprising the assignment and revocation of access permissions and the management of keys. In order to gain full advantage of Keeto a PKI and associated processes have to be present. Optionally a strong protection mechanism for private keys such as a Smartcard can be used to increase the level of security.Having all access permissions in a central repository highly simplifies its management with regards to the assignment/revocation and overview of permissions. Keeto represents access permissions through different access profile types that are assigned to OpenSSH servers centrally in an LDAP aware Directory Service such as OpenLDAP or Active Directory. Two different access profile types are supported enabling either direct access or access on behalf of another account.
Proper key management is vital to maintain the security of services. This comprises the secure generation of key material with approved tools and security parameters, the secure distribution and installation of keys and an appropriate key lifecycle management including the revocation, regeneration and removal of keys.
OpenSSH uses its own key format that solely consists of the data needed for the cryptographic operation during authentication. In comparison to X.509 certificates there is no binding to an identity, no integrity protection, no expiration and no mechanism for revocation.
This properties can either lead to manual processes or insecure handling of the key material. In a worst case scenario OpenSSH keys are
Those issues can be mitigated with a product solely focussing on the management of OpenSSH keys. However if a PKI is present this will result in two extensive software layers and processes that need to be maintained for the management of key material.
Instead of managing OpenSSH keys himself Keeto introduces support for X.509 certificates to OpenSSH. As X.509 certificates are already managed by a PKI no new processes e.g. key generation, periodical regeneration or revocation have to be established. Furthermore the protocol between the SSH client and the OpenSSH server remains untouched. Every SSH aware client can be used transparently without any modification. The distribution and proper installation of OpenSSH keys is handled by Keeto on each connection attempt after access permissions and the X.509 certificates have been successfully verified.
Keeto hooks into the standard PAM interface making it relatively independent from changes to OpenSSH itself. This implies that no modification of the OpenSSH source code is needed in order to run Keeto.
An SSH server entry is the starting point for the determination of access permissions and consists of various references to access profiles. It is identified by a unique identifier.
A direct acess profile specifies key providers that shall have direct access to the OpenSSH server. In this example a group of key providers is referenced.
The key provider group consists of references to people entries that provide the key material.
All key providers need an entity with a uid and certificate set. This is supposed to be already part of the DIT and managed by the PKI.
Keystore options can be specified to restrict access to the OpenSSH server.
Access is only allowed from an IP address of the '192.168.118.0/28' network.
The user 'birgit' is now able to login from the specified network. The keystore is installed in a way preventing it from non-privileged modifications.
Every protocol that relies on SSH for authentication can be used. Here SFTP is used for secure file transfer.
In this example we will have a look on how access on behalf profiles are specified. Again we start with an SSH server entry.
Access on behalf profiles have target keystores. A target keystore determines the destination keystore that receives the key providers keys.
A target keystore entry only needs to have a uid set. This uid is compared against the uid of the user about to login during authentication.
The key provider group ultimately specifies the keys that are synced into the target keystore.
In this example there are two key providers 'sebastian' and 'bjoern'.
Key provider entry from 'sebastian'...
... and from 'bjoern'.
The user 'sebastian' is now able to login on behalf of the account 'keeto'.
So is 'bjoern'...
Keeto is released under the terms of the GPLv3 license and actively developed by Sebastian Roland. The source code is hosted at and freely available for everyone. Information on how to install and configure Keeto can be obtained from the Docs.
You just wanna have a quick look without going through all the installation efforts? Check the Keeto image! See the Docs for all relevant information.
You like the project and want to join? Your help is highly appreciated! Currently searching for: