Package: github-ssh-auth
GitHub-SSH-AuthAboutIf you are familiar withauthorized_keysfile, each time you want to update keys, you have to first copy them usingssh-copy-idfor example or any similar method.But what happens if you fail to copy keys? You might be locked out of your box.Same applies when you want to deploy your configuration on several machines, or when you want to update keys for a whole team.
All these tasks are tedious and error-prone.AnsibleorChefcan help but they are not always available or suitable for the task.
They usually require some kind of infrastructure to work, and are designed for the whole system, not only forSSHauthentication of potentiallysomeusers.Another possible solution would be to have some common infrastructure likesssdorLDAPto deport the authentication some place else, or to somewhat automagically update the keys upon valid logon credentials.But what if you don't have such infrastructure? Or what if you don't want to have one?This is where this tool can help you out !How it worksThis project provides a way forSSHdaemon (akasshd) to authenticate users from your organization using their GitHub SSH keys.OpenSSHhas two options in its configuration file (e.g./etc/ssh/sshd.conf), namelyAuthorizedKeysCommandandAuthorizedKeysCommandUser. These two options are used to specify the command to run and the user to run it as.Therefore here is another technique that can help in such scenarios.Everytime a user connects, the script will be called with the login as command line parameter.In detail, the following happens :sshddeamon runsgithub-ssh-authunder the user defined byAuthorizedKeysCommandUseroption.github-ssh-authreads its configuration file (by default/etc/github-ssh/conf)according to the configuration file, it looks up the username given bysshdand checks if that user is granted permission to connect to this hostif yes, it tries to read the cache file (recommended but can be disabled) to find user's keys. If no cache file found or if disabled, then it queries GitHub API to get the keys and creates the cache (if enabled).github-ssh-auth returns a list of eligible ssh public keys to standard output to be processed bysshdThe rest is handled bysshditself, i.e. checking validity of that public key and the rest of the connection handling.It does not interfere with the rest of the system, including anything PAM related.Updating keys and cache useTo avoid flooding GitHub API and consequently being temporarily banned from using their API in case of massive connects, it is recommended to have cache enabled and update the keys only few times a day. The periodicity is yours and that is why there is a specialupdatecommand line parameter for that.Consider the following scenario:cache is enabledcache file already existsa new user has joined the team OR an existing user replaced his/her keysIn such case, the cache file willNOTbe updated when authentication happens, this is the behavior set by design to separate concerns and prevent connection to the outside world being in the critical path for authentication.Instead, a locally definedcronshould either:callgithub-ssh-updateto update cachedelete cache file (by default/etc/github-ssh/cache.json) which will force recreation when next auth happensBoth will have the same outcome but the former is cleaner than the latter.All in all, choice is yours :wink:InstallationSince this Python module deals with SSH authentication, it should be installed globally, hence:sudopipinstallgithub-ssh-authThis will install the following program and its shortcuts in/usr/local/bin:github-sshThe real application, handling all options, but for convenience the shortcuts described after can be used.UsageUsage:github-ssh[OPTIONS]COMMAND[ARGS]...

Options:--versionShowtheversionandexit.--helpShowthismessageandexit.

Commands:authAuthenticateuser.initInitializeGitHubSSHAuthenticationconfigurationfile.updateUpdateGitHubSSHAuthcachefile(users,teams,keys).github-ssh-authResponsible for authentication itself, this one is to be called bysshditself.Usage:github-ssh-auth[OPTIONS]LOGINAuthenticateuser.

Options:-c,--configFILEConfigfiletouse.[default:/etc/github-ssh/conf]--helpShowthismessageandexit.github-ssh-initThis command initializes the configuration file.
It will also launch an editor of your choice (or the one specified inEDITORenvironment variable) to edit the configuration file.Note: if the configuration file already exists, it willNOTbe overwritten.Usage:github-ssh-init[OPTIONS]InitializeGitHubSSHAuthenticationconfigurationfile.

Options:-c,--configFILEConfigfiletouse.[default:/etc/github-ssh/conf]-e,--editorFILEEditortouse.[default:vim]--helpShowthismessageandexit.github-ssh-updateResponsible for updating cache file, it can be scheduled to run periodicaly to ensure synchronization with updated keys from Github.Usage:github-ssh-update[OPTIONS]UpdateGitHubSSHAuthcachefile(users,teams,keys).

Options:-c,--configFILEConfigfiletouse.[default:/etc/github-ssh/conf]--helpShowthismessageandexit.Note:
In some distros,/usr/local/binis not eligible forsshddaemon because of some obscure group permissions reason. Moving the binaries (or create symlinks) from/usr/local/binto/usr/binmake them work like a charm !ConfigurationSSH configuration in/etc/ssh/sshd_configThese lines should be somewhere in yoursshdconfiguration file. Usually in/etc/ssh/sshd_config:AuthorizedKeysCommand/usr/bin/github-ssh-auth%u
AuthorizedKeysCommandUsernobodyWhat do they mean?The first line tellssshdto rungithub-ssh-authwith the username as command line parameter.
As previously said, recent versions ofsshdsupportAuthorizedKeysCommandoption and only if command happens to live in/usr/binnot/usr/local/bin.The second line tellssshdto rungithub-ssh-authundernobodyuser. This is to prevent any possible privilege escalation.GitHub token requirementsSince this application is dealing with some sensitive data (users and their team memberships) within an organization, we will need to create a so-calledPersonal access tokens.To do that, fire up your GitHub organization dashboard, look forSettingsthenDeveloper settings.Then click onGenerate new tokenand set its permissions to:read:orgThis is the only requirement so that the API can be queried for users and teams memberships. All users keys are public by default and can be accessed from the outside world without authentication against GitHub API.See for yourself, go tohttps://github.com/<yourhandle>.keys. :rocket:GitHub SSH Auth configuration fileIt resides by default in/etc/github-ssh/confbut of course you can change it using-cflag when calling (see above).The format is a standard INI style.Configuration file templateBelow is the complete grammar with inline comments:[global]# Comments should start with a # and must be full lines# The following two lines are mandatoryaccess_token=<token>organization=<org># In case of connectivity lost and to prevent too many connections to GitHub API,# it is strongly recommended to set it to an absolute filepath.# Default (when not present) is set to /etc/github-ssh/cache.json and equivalent to:# cache_file = /etc/github-ssh/cache.json# If you want to disable, set it to 'false'# cache_file = [/path/to/file | false]# Unless overridden after, users (whether individual or teams) will have these configurations applied.# By default, nothing is set so basically no one will be granted access# The '<' case means that if a local exists with the same name as a GitHub user,# it will be granted access. It is a shorthand to avoid a too# complex, verbose yet common use case where every developer would# like to have his/her own shell account.teams_default=[ list,of,local,users,or,< ]users_default=[ list,of,local,users,or,< ]# Configuration below will override team defaults[teams]<team_name>=[ list,of,local,users,or,< ]...# And below to override default users setup[users]<user_name>=[ list,of,local,users,or,< ]...Special note on the '<'Just a quick focus on that special caracter, designed to allow a GitHubuserto connect provided that:useris the Github handle, being part of the organization,anduserexists in the local user base (i.e. it is present when you do agetent passwd)Real world exampleLet's say Acme Corp. wants all its developers connect with their GitHub accounts. Let's say usersjdoebobaliceare such handles. Also these user handles are also the respective handlers in GitHub.Then with this simple configuration, we allow globally all these users to login with their handles:[global]...other config skipped for brevety...users_default=<Now if you only wantbobto connect using loginbob, the configuration file would look like this one:[global]...other config skipped for brevety...users_default=[users]bob=<Other real world examplesSome other ready-to-be-deployed-or-almost can be found in theexampledirectory.TestingAs this is my first Python module, and even my first Python program ever, I tried different methods to handle testing.Have had a lot of shortcomings four years ago when I started this project, now I found a way to test it properly usingtoxandpytest.
Of course code iscoverage-driven, so you can usecoverageto get an idea of what is covered and what is not.An html report is also generated bycoverageand can be found in.tox/htmlcov/index.html.I therefore removed the previous stack of tests usingDockerfileandMakefile.ContributionsComments, issues, PR as :beer: will be warmly welcomed !LicenseGPLv3+