Skip to content

Instantly share code, notes, and snippets.

@sivel
Last active October 22, 2025 19:48
Show Gist options
  • Save sivel/c68f601137ef9063efd7 to your computer and use it in GitHub Desktop.
Save sivel/c68f601137ef9063efd7 to your computer and use it in GitHub Desktop.

Revisions

  1. sivel revised this gist Sep 13, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions better-ssh-authorized-keys-management.md
    Original file line number Diff line number Diff line change
    @@ -30,14 +30,14 @@ ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCZ0N1dcto3td7j5/7UPCE2XlhDaCOZTlYtCgNifJyg
    If I were to serve out the `users/` directory using a webserver such as nginx, I might be able to request the keys for the user `matt` such as:

    ```
    curl -sf http://keyserver.example.org/users/matt/keys
    curl -sf https://keyserver.example.org/users/matt/keys
    ```

    The `AuthorizedKeysCommand` expects an executable that takes a single argument, which is the username to retrieve the keys for. An example executable may look like:

    ```bash
    #!/bin/bash
    curl -sf http://keyserver.example.org/users/$1/keys
    curl -sf https://keyserver.example.org/users/$1/keys
    ```

    Name this file something like `/usr/local/bin/userkeys.sh` and make it executable: `chmod a+x /usr/local/bin/userkeys.sh`
  2. sivel revised this gist Aug 12, 2014. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions better-ssh-authorized-keys-management.md
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@

    A seemingly common problem that people encounter is how to handle all of your users authorized_keys file.

    People struggle over management, ensuring that users only have specific keys in the authorized_keys file, that keys are expired regularly
    People struggle over management, ensuring that users only have specific keys in the authorized_keys file or even a method for expiring keys. A centralized key management system could help provide all of this functionality with a little scripting.

    One piece of functionality overlooked in OpenSSH is the `AuthorizedKeysCommand` configuration keyword. This configuration allows you to specify a command that will run during login to retrieve a users public key file from a remote source and perform validation just as if the authorized_keys file was local.

    @@ -40,7 +40,7 @@ The `AuthorizedKeysCommand` expects an executable that takes a single argument,
    curl -sf http://keyserver.example.org/users/$1/keys
    ```

    Name this file something like `/usr/local/bin/userkeys.sh` and make it executable: `chmod a+x userkeys.sh`
    Name this file something like `/usr/local/bin/userkeys.sh` and make it executable: `chmod a+x /usr/local/bin/userkeys.sh`

    Now add the following to your `/etc/sshd/sshd_config` file:

    @@ -49,16 +49,16 @@ AuthorizedKeysCommand /usr/local/bin/userkeys.sh
    AuthorizedKeysCommandUser nobody
    ```

    *Most operating systems have a nobody user, but you can replace that user with any non-root user that is different from the user running OpenSSH on the server*
    *Most operating systems have a nobody user, but you can replace that user with any non-root user that is different from the user running OpenSSH on the server. This should preferably be a user not already in use by another daemon.*

    Now, when a user logs in, `userkeys.sh` will be executed and if there are keys for that user they will be returned by our simple script.

    Now all you need to do is just manage that `users/` directory via something like git and you are good to go.
    Now all you need to do is manage that `users/` directory via something like git and you are good to go.

    ## GitHub

    If all your users are on GitHub, you can even have them use GitHub for the storage location of their SSH public keys, and you can replace the URL with `https://github.com/$1.keys`.

    Although, if you usernames don't match GitHub, then you would have to maintain a lookup table that may get complicated.

    *This also works for GitHub Enterprise too*
    *This also works for GitHub Enterprise too, which if your company uses it could solve the username issues.*
  3. sivel revised this gist Aug 12, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion better-ssh-authorized-keys-management.md
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # Better Authorized Keys Management
    # Better SSH Authorized Keys Management

    A seemingly common problem that people encounter is how to handle all of your users authorized_keys file.

  4. sivel renamed this gist Aug 12, 2014. 1 changed file with 0 additions and 0 deletions.
  5. sivel revised this gist Aug 11, 2014. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions better-authorized-keys-management.md
    Original file line number Diff line number Diff line change
    @@ -57,6 +57,8 @@ Now all you need to do is just manage that `users/` directory via something like

    ## GitHub

    If all your users are on GitHub, you can even have them use GitHub for the storage location of their SSH public keys, and you can replace the URL with `https://github.com/$1.keys`
    If all your users are on GitHub, you can even have them use GitHub for the storage location of their SSH public keys, and you can replace the URL with `https://github.com/$1.keys`.

    Although, if you usernames don't match GitHub, then you would have to maintain a lookup table that may get complicated.
    Although, if you usernames don't match GitHub, then you would have to maintain a lookup table that may get complicated.

    *This also works for GitHub Enterprise too*
  6. sivel created this gist Aug 11, 2014.
    62 changes: 62 additions & 0 deletions better-authorized-keys-management.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,62 @@
    # Better Authorized Keys Management

    A seemingly common problem that people encounter is how to handle all of your users authorized_keys file.

    People struggle over management, ensuring that users only have specific keys in the authorized_keys file, that keys are expired regularly

    One piece of functionality overlooked in OpenSSH is the `AuthorizedKeysCommand` configuration keyword. This configuration allows you to specify a command that will run during login to retrieve a users public key file from a remote source and perform validation just as if the authorized_keys file was local.

    Here is an example directory structure for a set of users with SSH public keys that can be shared out via a web server:

    ```
    users/
    ├── dave
    │   └── keys
    ├── matt
    │   └── keys
    ├── nathen
    │   └── keys
    └── paul
    └── keys
    ```

    Each of these keys files might look like:

    ```
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCt8lGmfZ0fxPz/66JlNg9CmZNaLsJ/TDrYnpBpiWWeuoLxP1tEbDiutApVOkjjQszBQV6CgvG3PeBYYAcJxUTRKhY8dUUbsAvVK3SRVwpr8jhtcohYgRE4V9/xPnwilDAfd9TymCMvM/mBpauQCyL40SImFQMJl5aBAhBiy6zyWx6WeDTzJ4+ZGUTmwFFyaWzzIqIZXWe1QiM98rfzle0mYM8KSKdTuGEf0EmY63MbMl3PQ61ms/qkR3fnKWpGF+EsigS0NgT6nBYoOZm5nFtrB2WM8nixyD5v82Z6yA6+O2SfLxtzJ6OcowtwtitrcZrAZdcNIwOAX1T7G4qcFEFn [email protected]
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCZ0N1dcto3td7j5/7UPCE2XlhDaCOZTlYtCgNifJygM5GNAG97JcChnnoYbdmiEM+dFMs7Jk6fS/WzG0Q0Ypu3rQ9AzzeUEMbhrFB90f28JsfUtgnkYuUF+1dNDGZn1fhYMlNwwyIt5s0KSS18iJNU6ZrSTudk9v1gyBM+Sxz97YMg2RiiGpCajPHzZbj2AwMl52MjT8ZDCGLt2qFo+w4u4BNQdtAA+zs/GiwgFbdGHM2HR1VxmII61LpvyyeuRkRwxN1ak3R7FcPMmYNhC9cvzbnvpmVcXxwXChI/9ceOm6DODCgHl9YeOgngoe5gEtZHnqtOWZWao8cFfd4wcEEN [email protected]
    ```

    If I were to serve out the `users/` directory using a webserver such as nginx, I might be able to request the keys for the user `matt` such as:

    ```
    curl -sf http://keyserver.example.org/users/matt/keys
    ```

    The `AuthorizedKeysCommand` expects an executable that takes a single argument, which is the username to retrieve the keys for. An example executable may look like:

    ```bash
    #!/bin/bash
    curl -sf http://keyserver.example.org/users/$1/keys
    ```

    Name this file something like `/usr/local/bin/userkeys.sh` and make it executable: `chmod a+x userkeys.sh`

    Now add the following to your `/etc/sshd/sshd_config` file:

    ```
    AuthorizedKeysCommand /usr/local/bin/userkeys.sh
    AuthorizedKeysCommandUser nobody
    ```

    *Most operating systems have a nobody user, but you can replace that user with any non-root user that is different from the user running OpenSSH on the server*

    Now, when a user logs in, `userkeys.sh` will be executed and if there are keys for that user they will be returned by our simple script.

    Now all you need to do is just manage that `users/` directory via something like git and you are good to go.

    ## GitHub

    If all your users are on GitHub, you can even have them use GitHub for the storage location of their SSH public keys, and you can replace the URL with `https://github.com/$1.keys`

    Although, if you usernames don't match GitHub, then you would have to maintain a lookup table that may get complicated.