4 ms·
Am I understanding that the public keys used for authorization (authorized_keys) can come from a centralized source? Being able to add and remove authorized key
by nodesocket 5y ago
Am I understanding that the public keys used for authorization (authorized_keys) can come from a centralized source? Being able to add and remove authorized keys from say Redis or Consul centrally would be extremely useful from a management perspective.
Obviously, security of that Redis or Consul would have to be tight and prevent public access.
- frutiger 5y agoSlightly off-topic, but OpenSSH already supports this via `AuthorizedKeysCommand`: https://man.openbsd.org/sshd_config#AuthorizedKeysCommand https://man.openbsd.org/sshd_config#AuthorizedKeysCommand
- nodesocket 5y agoOh really interesting. Any good guides you know of how to implement AuthorizedKeysCommand with Redis for example?
- macno 5y agoHi @nodesocket, you can take a look how we solved it with Theo https://theoapp.readthedocs.io/en/latest/index.html https://theoapp.readthedocs.io/en/latest/index.html It supports fine hosts/users grants - i.e. I can connect as "dev" user on servers "node1" and "node2" but not on "node3" - and it leverages asymmetric key signing to validate the public SSH keys. Theo supports mysql/mariadb/sqlite/postgresql(experimental) for storing data and redis/memecached for caching. Happy to answer any further questions!
- frutiger 5y agoI'm not really an expert on redis. Perhaps one can fashion something with `redis-cli`? Or write a program that links the redis client library.
- m_sahaf 5y agoThat's right! Currently such (static) keys are loaded at provision-time, when the server is first booting up, but there's nothing preventing it from being lazy-loaded at authentication-time. Of course loading them at authentication-time incurs latency as tax. Nothing prevents two separate modules from existing: one eager-loads the keys, and another lazy-loads them.