The Akeyless Dev Hub

If you're looking for help with the only zero-trust, SaaS, unified platform for secrets management - you've come to the right place.

This is our documentation and updates center.


How to: Configure Keyless SSH


Via a single sign-on, Akeyless Vault connects an ssh client to the server, using your chosen Authentication Method (or through your Identity Provider) while using existing Access Groups and Policies in your environment.
Instead of issuing an SSH key pair - public and private, Akeyless provides ephemeral SSH certificates to allow access over standard SSH protocol, while eliminating the need for public SSH keys on the server side.


SSH Certificate

Akeyless SSH Certificate issuer allows to eliminate key approval and distribution of keys in static files of Hosts and Clients. More on SSH Certificates here.

SSH Certificate Issuer

You can define several SSH CA's (certificate authority), each one can sign your SSH public keys, with ancillary data like expiration date, principals, extensions, etc.
You can sign the certificate with your own private key, or generate new one in Akeyless Vault.


Prior to creating SSH cert. issuer you should upload your CA (RSA private key) for signing the client SSH certificate:

akeyless upload-rsa --name your-RSA-key-name --alg RSA2048 --rsa-key-file-path Path-to-RSA.pem

Alternatively, you can create a new RSA key in Akeyless Vault:

akeyless create-key --name your-RSA-key-name --alg RSA2048

In case you create a new private key, you should fetch the public key to use it on your host machine:

akeyless get-rsa-public --name your-RSA-key-name

Example output:

- RAW: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA84EWkhcdbZHE7vrYKjh33fo4NC/9Xu3l3n7tTD2d4iN+c6B4hTn1IbiquSFOA89zd/GgaPmzisJ3PMqYy3cPvRJc7VWRu72wR9muOdHX3vP7bscR+fGgKuOn1XPXBPjsOmof1QKbQ3udxMRY+9NaN82zUp6itroCu/gjG9lySxwPgzIS8pgC/jD4zEhnPp+OCP20fH23wn9++o6nIResVBZXIdnYR2v3msX7+qhkkz1RIBVn1MWKfinHq7zFFG1Q6gpAs1FcbU3fsVd2wzs4WeJTKQDC5908moqwj83yKhuMFCRU1gnpileWdG5b8c1LmZ5FlB0XUp6MMV8gDakHGQIDAQAB
- SSH: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDzgRaSFx1tkcTu+tgqOHfd+jg0L/1e7eXefu1MPZ3iI35zoHiFOfUhuKq5IU4Dz3N38aBo+bOKwnc8ypjLdw+9ElztVZG7vbBH2a450dfe8/tuxxH58aAq46fVc9cE+Ow6ah/VAptDe53ExFj701o3zbNSnqK2ugK7+CMb2XJLHA+DMhLymAL+MPjMSGc+n44I/bR8fbfCf376jqchF6xUFlch2dhHa/eaxfv6qGSTPVEgFWfUxYp+KcervMUUbVDqCkCzUVxtTd+xV3bDOzhZ4lMpAMLn3TyairCPzfIqG4wUJFTWCemKV5Z0blvxzUuZnkWUHRdSnowxXyANqQcZ

Please copy only the SSH format (starting from “ssh-rsa…“) and copy it to a file on the SSH server, i.e. /etc/ssh/trusted

Create SSH Certificate Issuer - CLI

The following command will create a new SSH Cert Issuer in Akeyless Vault with ancillary data.

  • signer-key-name: The private key to be used for certificate signing
  • allowed-users: Users allowed to use the certificate (supports wildcard)
  • principals: A specific set of SSH Certificate principals
  • expiration-sec: Certificate time period until expiration
  • extensions: A specific set of SSH Certificate extensions. Default extensions: permit-X11-forwarding, permit-agent-forwarding, permit-port-forwarding, permit-pty, permit-user-rc.
akeyless create-ssh-cert-issuer --name /prod/ssh-cert-issuer --signer-key-name /prod/prod-bastion --allowed-users 'ubuntu,root' --ttl 300


Please note for SSH Bastion you should run

akeyless create-ssh-cert-issuer --name /prod/ssh-cert-issuer --signer-key-name /prod/prod-bastion --allowed-users 'ubuntu,root' --allowed-users 'session_*' --ttl 300

Create SSH Certificate Issuer - UI

The following figure depicts creation of a new SSH Cert. Issuer using the Web UI.

Client SSH Authentication - CLI

The following steps are performed by the user that wishes to authenticate to a remote server.
In order to sign your public key please use the following command:

akeyless get-ssh-certificate --cert-username ubuntu --cert-issuer-name /prod/ssh-cert-issuer --public-key-file-path ~/.ssh/


The command get-ssh-certificate returns a certificate that is signed by the private CA key and uses the client’s public key that will used to connect to the target server. The client public key is not the same as the CA’s public key. It is a local public key which should be located in the command’s path together with the client’s private key. After you run the command, the signed certificate will be placed in the same path, so you will be able to connect to the target server using the client’s private/public keys which are located on the same path.

The outcome of this command will be creating a new file beside the public key, with adding a suffix to its name with (~/.ssh/ This is a well known convention with the OpenSSH use is during authentication.

  • cert-username: The username to sign in the SSH certificate
  • cert-issuer-name: The name of the SSH certificate issuer to use for signing
  • public-key-file-path: SSH public key file path for signing

Configure Target Server

To enable certificate authentication you should configure the target server to trust any certificates signed by your CA's public key.
1 - Fetch the CA's public key from your Akeyless account via the following command:
akeyless get-rsa-public --name
the output should be contains two sections, one in a row format and the other in SSH format.
2 - Copy the Public Key with thw SSH format from step 1 (ssh-rsa AAAAB3NzaC1yc2EAAAA...) to a new file /etc/ssh/trusted on the server that will be accepting SSH connections.

ssh-rsa AAAAB3NzaC1yc2EAAAA...

SSH Principals


Please note that the AuthorizedPrincipalsFile is optional.
If you choose to use it, it needs to matched with the principals listed in the SSH Cert Issuer you created.

3 - Add the lines below to /etc/ssh/sshd_config. Once done the sshd service may need to be restarted
TrustedUserCAKeys /etc/ssh/trusted
AuthorizedPrincipalsFile /etc/ssh/principals

TrustedUserCAKeys /etc/ssh/trusted
AuthorizedPrincipalsFile /etc/ssh/principals

Updated 2 months ago

How to: Configure Keyless SSH

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.