Manage the authorized keys for a host, based on group/role membership (i.e. Github Group).
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Vincent Batts bd1f1a83b2 Adding discovered prior works 2 months ago
LICENSE Initial commit 2 months ago Adding discovered prior works 2 months ago


Manage the authorized keys for a host, based on group/role membership (i.e. Github Group).


In sshd_config there is a configuration AuthorizedKeysCommand with the following description:

Specifies a program to be used to look up the user's public keys. The program must be owned by root, not
writable by group or others and specified by an absolute path. Arguments to `AuthorizedKeysCommand`
accept the tokens described in the TOKENS section. If no arguments are specified then the username of
the target user is used.

The program should produce on standard output zero or more lines of authorized_keys output (see
AUTHORIZED_KEYS in sshd(8)). `AuthorizedKeysCommand` is tried after the usual `AuthorizedKeysFile`
files and will not be executed if a matching key is found there. By default, no `AuthorizedKeysCommand`
is run.

The workflow would be: When deploying a node, the command would be configured with it's auth token and the group/role/team. When a user ssh's to the host, the command checks the members of the group, and the corresponding pubkeys for this user set.

Further improvements can be:

  • periodic caching/purging of the available keys
  • mapping of the user name being ssh'ed to (i.e. core vs build, etc)

For github, the user's ssh keys are available by appending .keys to the user's URL. For example, my are

As an example test, I've added to my /etc/ssh/sshd_config:

AuthorizedKeysCommand /opt/bin/authorized_keys fgr="%f" home="%h" key="%k" ktype="%t" uid="%U" user="%u"
AuthorizedKeysCommandUser nobody

and created a shell script at /opt/bin/authorized_keys:


set -eu

echo "$@" >> /tmp/xx

and adduser test a dummy user to ssh test@localhost. Now /tmp/xx has all the public keys in from my current user's ssh-agent:

fgr="SHA256:jh7FlZkLnOxIVEoNYaJXjM+funB3kT1rkn/SOLIrDVw" home="/home/test" key="AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAABAIbmlzdHA1MjEAAACFBABNaiMzEtWCNDMsBd6fsUzYRhcifWXPCGyRnuAfuDSoP8Od/95xn6i1mQBgqt8S+gRPcO92nIn3OVXGx0IXXsuu8QEx3QuLiMBhTN+Boae+bs+Fo5Dg0CRrP9Qd7efeQNUZ83X5FY1rYsTpG7A6DL73EZxi/Er3HBAgtFV1iN1VGUzofg==" ktype="ecdsa-sha2-nistp521" uid="1001" user="test"
fgr="SHA256:Fo0hGLTLki9TdbOX43CmfiqdkIgMEiF57W3AcovaK7E" home="/home/test" key="AAAAC3NzaC1lZDI1NTE5AAAAIJEuxEjjdx5+vMAHfYvqf9Fzx3cDNyAxi6jsjLL1q/uJ" ktype="ssh-ed25519" uid="1001" user="test"

Discovered prior work