{"id":37150608,"url":"https://github.com/advuni/vault-plugin-secrets-ssh-pubkey","last_synced_at":"2026-01-14T17:47:55.560Z","repository":{"id":144240598,"uuid":"210313951","full_name":"AdvUni/vault-plugin-secrets-ssh-pubkey","owner":"AdvUni","description":"Variation of Vault's builtin SSH Secrets Engine","archived":false,"fork":false,"pushed_at":"2019-09-26T12:24:23.000Z","size":1771,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2023-03-21T20:18:16.103Z","etag":null,"topics":["dynamic-secrets","plugin","secrets-engine","vault"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AdvUni.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-09-23T09:20:40.000Z","updated_at":"2024-06-19T08:55:23.075Z","dependencies_parsed_at":null,"dependency_job_id":"813698ad-5669-464d-9a31-6988846df5ae","html_url":"https://github.com/AdvUni/vault-plugin-secrets-ssh-pubkey","commit_stats":null,"previous_names":[],"tags_count":0,"template":null,"template_full_name":null,"purl":"pkg:github/AdvUni/vault-plugin-secrets-ssh-pubkey","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AdvUni%2Fvault-plugin-secrets-ssh-pubkey","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AdvUni%2Fvault-plugin-secrets-ssh-pubkey/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AdvUni%2Fvault-plugin-secrets-ssh-pubkey/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AdvUni%2Fvault-plugin-secrets-ssh-pubkey/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AdvUni","download_url":"https://codeload.github.com/AdvUni/vault-plugin-secrets-ssh-pubkey/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AdvUni%2Fvault-plugin-secrets-ssh-pubkey/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28428936,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-14T16:38:47.836Z","status":"ssl_error","status_checked_at":"2026-01-14T16:34:59.695Z","response_time":107,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dynamic-secrets","plugin","secrets-engine","vault"],"created_at":"2026-01-14T17:47:54.822Z","updated_at":"2026-01-14T17:47:55.530Z","avatar_url":"https://github.com/AdvUni.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Vault Plugin: SSH-Pubkey Secrets Engine\n\nThis is a secrets backend plugin for use with [Hashicorp Vault](https://www.github.com/hashicorp/vault).\nThis Secrets Engine is for granting access to SSH machines.\n\nIt is a variation of Vaults [builtin SSH Secrets Engine](https://www.vaultproject.io/docs/secrets/ssh/index.html), providing something like a fourth mode. It offers SSH access through normal public key authentication.\n\nAll functions of the Secrets Engine are fully documented in the [API reference](doc/api_reference.md).\n\n## Why another SSH Secrets Engine?\nVaults [builtin SSH Secrets Engine](https://www.vaultproject.io/docs/secrets/ssh/index.html) already provides three different modes for accessing SSH machines:\n* [Signed SSH Certificates](https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates.html)\n* [One-time SSH Passwords](https://www.vaultproject.io/docs/secrets/ssh/one-time-ssh-passwords.html)\n* [Dynamic SSH Keys](https://www.vaultproject.io/docs/secrets/ssh/dynamic-ssh-keys.html)\n\nBut they all have their drawbacks.\n\nAlthough One-time Passwords are an elegant authentication mechanism, they just don't fit every use case.\n\nThe Dynamic Key mode is useful, but its handling of SSH keys is a bit weird. It generates key pairs and uploads the private key to the target machine's `authorized_keys` file while returning the private key to the user. Afterwards, the user can log into the target machine using the private key. This behavior kind of bypasses the advantages of public key authentication. Actually, the private key should always be generated by the user himself. Otherwise, SSH keys not differ much from very unhandy passwords. The Dynamic Key mode was deprecated by HashiCorp anyway.\n\nThe alternative is the Signed certificates mode. It is identified by Vault as the \"simplest and most powerful\" mode. Here, a user provides his own public key to Vault. The Secrets Engine has a key pair itself and uses it to sign the user's key. Then it returns the signature in form of a certificate to the user. The user now can use its own private key together with the certificate and log into every SSH machine, where the Secrets Engine's public key is registered as CA. This is an elegant solution since no private keys have to be transmitted during the signing process and each user can use its personal key pair for as many signing requests as he wishes. \n\nBut so the user needs to provide two files for authentication, both the certificate and the private key. Further, the certificate changes for each signing request, so it must be downloaded from the Secrets Engine each time. Another flaw is, that Vault has no possibility to revoke certificates once they are created. Hence the Signed Certificate mode does not create [Leases](https://www.vaultproject.io/docs/concepts/lease.html) providing the advantages of [Dynamic Secrets](https://www.hashicorp.com/blog/why-we-need-dynamic-secrets), as advertised by HashiCorp.\n\nSo why there is not another mode, which combines the modes dynamic keys and signed certificates? This is what the SSH-Pubkey plugin tries to accomplish. It uploads SSH public keys to the `authorized_keys` file of a target machine allowing the owner of the private key to log in, but it requests the public key from the user instead of generating it itself. Further, the Secrets Engine returns a lease with the possibility to renew or revoke the access immediately. As long as the lease is valid, users can do real public key authentication towards the target machine only using their personal key pair without copying, downloading or forwarding any information from Vault at all. The same keys can be used over different leases.\n\n## Usage\nDownload the code with\n```sh\ngo get -u github.com/AdvUni/vault-plugin-secrets-ssh-pubkey\n```\nMove into `~/github.com/AdvUni/vault-plugin-secrets-ssh-pubkey` and compile the plugin with\n```sh\ngo build -o ssh-pubkey-plugin\n```\n\nNext, the plugin needs to be [registered](https://www.vaultproject.io/docs/internals/plugins.html#plugin-registration) in vault. Note that you therefore need to specify a [plugin directory](https://www.vaultproject.io/docs/configuration/index.html#plugin_directory) and the [api-address parameter](https://www.vaultproject.io/docs/configuration/index.html#api_addr) in your vault configuration first. \n\nEnable the plugin, configure it and define a role. Then, the `creds` endpoint can be used to grant an ssh key access to the target machine:\n```sh\nvault write ssh-pubkey/creds/my_role public_key=\"ssh-rsa AAAAB3NzaC1yc2EAA...\"\n```\nAfterwards, the corresponding private key can be used for logging into the target machine via normal public key authentication:\n```sh\nssh -i id_rsa user@example-url\n```\nif the ssh key pair lays in the `.ssh` folder in your home directory, you can even omit to specify it with the `-i` parameter.\n\nFor full reference see the API documentation under [doc/api_reference.md](doc/api_reference.md)\n\n## Code and functionality\nThis Plugin was written by copying and modifying the [Code from the builtin SSH Secrets Engine](https://github.com/hashicorp/vault/tree/master/builtin/logical/ssh). The SSH-Pubkey plugin not includes the functionality of several modes at once and is therefore much simpler than the original Secrets Engine.\n\nIn particular, the tasks of the different request endpoints 'config', 'role' and 'creds' are determined a bit more clearly. Each instance of the SSH-Pubkey Secrets Engine addresses one specific target machine. This target machine is determined by URL or IP address at the endpoint `creds`. A role in contrast is for addressing one specific OS user at the target machine. This user's `authorized_keys` file gets changed when calling endpoint `creds` for the role. You always need a role for calling the `creds` endpoint.\n\nWith this concepts, there is no possibility for users to ask for custom IPs when requesting `creds` as in the builtin SSH Secrets Engine. Neither is there any need for specifying parameters like allowed CIDR blocks or Zero-Addresses.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fadvuni%2Fvault-plugin-secrets-ssh-pubkey","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fadvuni%2Fvault-plugin-secrets-ssh-pubkey","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fadvuni%2Fvault-plugin-secrets-ssh-pubkey/lists"}