Manage the authorized keys for a host, based on group/role membership (i.e. Github Group).
Go to file
Vincent Batts bd1f1a83b2 Adding discovered prior works 2021-03-09 16:22:38 +00:00
LICENSE Initial commit 2021-03-09 14:53:58 +00:00
README.md Adding discovered prior works 2021-03-09 16:22:38 +00:00

README.md

TeamAuthorizedKeys

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

Abstract

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 https://github.com/vbatts.keys

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:

#!/bin/bash

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