Google released the source code for HIBA, an identity authorization mechanism for SSH

Few days ago Google unveiled through a blog post the news of the release of the source code of the HIBA project (Host Identity Based Authorization), which proposes the implementation of an additional authorization mechanism to organize user access through SSH in relation to hosts (checking whether or not access to a specific resource is allowed when authenticating using public keys).

Integration with OpenSSH is provided by specifying the HIBA driver in the AuthorizedPrincipalsCommand directive in / etc / ssh / sshd_config. The project code is written in C and is distributed under the BSD license.

About HIBA

ERROR uses standard authentication mechanisms based on OpenSSH certificates for flexible and centralized management of user authorization in relation to hosts, but does not require periodic changes to the authorized_keys and authorized_users files on the side of the hosts to which it is connected.

Instead of storing a list of keys Valid public and access conditions in authorized files (keys | users), HIBA integrates the host binding information directly into the certificates themselves. In particular, extensions have been proposed for host certificates and user certificates, which store host parameters and conditions for granting user access.

While OpenSSH provides many methods, from a simple password to the use of certificates, each of them presents challenges in its own right.

Let's start by clarifying the difference between authentication and authorization. The first is a way of showing that you are the entity that you claim to be. This is usually accomplished by providing the secret password associated with your account or by signing a challenge that shows that you have the private key corresponding to a public key. Authorization is a way of deciding whether or not an entity has permission to access a resource, usually done after authentication occurs.

The host-side verification is started by calling the hiba-chk driver specified in the AuthorizedPrincipalsCommand directive. This handler decodes the extensions built into the certificates and, based on them, makes the decision to grant or block access. The access rules are defined centrally at the level of the certification authority (CA) and are integrated into the certificates at the stage of their generation.

On the certification center side, there is a general list of permissions available (hosts you can connect to) and a list of users who can use these permissions. The hiba-gen utility has been proposed to generate certificates with built-in permission information, and the functionality required to create a certificate authority has been moved to the hiba-ca.sh script.

During the user connection, the credentials specified in the certificate are confirmed by the digital signature of the certificate authority, which allows all verifications to be done entirely on the destination host side to which the connection is made, without contacting external services. The list of CA public keys that certify SSH certificates is specified by the TrustedUserCAKeys directive.

HIBA defines two extensions for SSH certificates:
The HIBA identity, attached to the host certificates, lists the properties that define this host. They will be used as criteria to grant access.
The HIBA grant, attached to user certificates, lists the restrictions that a host must meet in order to be granted access.

In addition to direct linking of users to hosts, HIBA allows you to define more flexible access rules. For example, hosts can be associated with information such as location and type of service, and by defining user access rules, allow connections to all hosts with a particular type of service or to hosts at a specific location.

Finally if you are interested in knowing more about it about the note, you can check the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.