Current thinking is:

1. use AuthorizedKeysCommand which runs a user defined command and accepting username as the argument and returns valid SSH key(s) to use for authentication
2. always return an emergency "break-the-glass" key
3. given the username, see if it's in our GH org, and if yes, see if that user has SSH keys, if yes, return those
4. allow for a list of extra username:key pairs to be baked in, or set as config in values.yaml - this allows external partners
5. set shell to /bin/false (or something similar) - to only allow tunnels and no shell commands.

Doing some prototyping and noticing:

• we may want to try and persist host key or some other house keeping around host key generation. otherwise users will see this the n+1 time the connect and the server has been recreated (a common occurrence in container land!):

  ssh test@localhost -p 2222 -o PubkeyAuthentication=no -o PreferredAuthentications=password              
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@             
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!  
  

• we should be sure to TBD harden SSH, but:
  • disable password login
  • disable root login
  • disable weak ciphers
  • require keys (same as disable passwords)
  • moar?
• while a bit out of date, I was able to build an image with alpine:latest from this repo (currently pinned to alpine:3.11.6 from ~4 years ago). It has a lot of well thought out ideas on how to structure env vars and such!