By sensitive data, we meant part of the identity of all our users (there is quite often user@host at the end of the public keys sent by our users), and the second point is linked to the internal commands.
In the `command="ssh-handler" ssh-rsa....` the command doesn't receive the SSH public key as argument, so we would have to provide additional information like:
`command="ssh-handler <user_id|username|key_id>" ssh-rsa....`
So yes, if we have a way to avoid having a copy of that on all our servers able to authenticate users, we take it!
Not yet.. I've set up a GitHub clone and had to patch OpenSSH: the authorisation process can execute an external command (AuthorizedKeysCommand option IIRC) but doesn't provide enough information to do a DB lookup à-la-GitHub.
The AuthorizedKeysCommand script is invoked with the user name of the connecting user, which isn't enough to do a database lookup, as, for example, on GitHub all incoming connections are from user git.
The patch basically makes OpenSSH send the incoming user key to the script's stdin, and from the key it's trivial to match it against a user.
AuthorizedKeysCommand doesn't scale. Particularly for Github and Bitbucket because they would need to return a few million lines.
From the man page:
Specifies a program to be used for lookup of the user's public keys. The program will be invoked with its first argument the name of the user being authorized, and should produce on standard output AuthorizedKeys lines (see AUTHORIZED_KEYS in sshd(8)). By default (or when set to the empty string) there is no AuthorizedKeysCommand run. If the AuthorizedKeysCommand does not successfully authorize the user, authorization falls through to the AuthorizedKeysFile. Note that this option has an effect only with PubkeyAuthentication turned on.
Post author here, unfortunately no, after some time, we realized it was quicker to develop a complete SSH server than patching some legacy C code. It was really confortable to work with go to do that.
Question by someone who has no real knowledge about the ssh protocol - is using something like this secure? And if not, what can be done to make their implementation secure?
Separately, I don't know what other - if any - features a db-backed ssh server needs to provide. Is this all that is necessary?
On the other hand, OpenSSH's server has become so big that even when it is perfectly implementing the security contract its authors intend it can still allow users to do things that may surprise the heck out of you. Given what I've seen of trying to secure things that use SSH and really shouldn't, I would believe it might be easier to audit your own server rather than a deployment of opensshd.
As jerf said, it's always difficult to see if an implementation of a protocol respects it completely. Most of us trust OpenSSH because of its background. It's old enough, the codebase is mature enough and maintained by the OpenBSD team. However it's quite a massive project, I don't know how they would be able that their implementation fits completely the 6 RFCs, I mean, more than the go implementation.
In our case, the SSH server is not for general purpose, but for something really specific, so it's really easier to test. What other feature? As I will explain next week, our SSH server is actually an authentication/autorization proxy which forwards connections to another server. By building our solution, it is now easier to control the logics for the load balancing etc.
12 comments
[ 3.6 ms ] story [ 40.8 ms ] threadThat’s two problems in one : we had to find a synchronization mechanism, and, sensitive data are spread out on several machines
I was confused by the implication that public keys are sensitive data. I guess the list of usernames and commands could be?
By sensitive data, we meant part of the identity of all our users (there is quite often user@host at the end of the public keys sent by our users), and the second point is linked to the internal commands.
In the `command="ssh-handler" ssh-rsa....` the command doesn't receive the SSH public key as argument, so we would have to provide additional information like: `command="ssh-handler <user_id|username|key_id>" ssh-rsa....` So yes, if we have a way to avoid having a copy of that on all our servers able to authenticate users, we take it!
GitHub explained in "How We Made GitHub Fast"(2009) [1] they patched their ssh daemon, so that it would do some lookups in a MySQL DB.
I wonder if daemons like OpenSSH now have some kind of plugin mechanism that lets one use their own lookup strategy.
[1]: https://github.com/blog/530-how-we-made-github-fast
The patch basically makes OpenSSH send the incoming user key to the script's stdin, and from the key it's trivial to match it against a user.
Here's a similar patch with the same purpose: https://github.com/norbauer/openssh-for-git
From the man page:
Specifies a program to be used for lookup of the user's public keys. The program will be invoked with its first argument the name of the user being authorized, and should produce on standard output AuthorizedKeys lines (see AUTHORIZED_KEYS in sshd(8)). By default (or when set to the empty string) there is no AuthorizedKeysCommand run. If the AuthorizedKeysCommand does not successfully authorize the user, authorization falls through to the AuthorizedKeysFile. Note that this option has an effect only with PubkeyAuthentication turned on.
Separately, I don't know what other - if any - features a db-backed ssh server needs to provide. Is this all that is necessary?
On the other hand, OpenSSH's server has become so big that even when it is perfectly implementing the security contract its authors intend it can still allow users to do things that may surprise the heck out of you. Given what I've seen of trying to secure things that use SSH and really shouldn't, I would believe it might be easier to audit your own server rather than a deployment of opensshd.
In our case, the SSH server is not for general purpose, but for something really specific, so it's really easier to test. What other feature? As I will explain next week, our SSH server is actually an authentication/autorization proxy which forwards connections to another server. By building our solution, it is now easier to control the logics for the load balancing etc.
Obviously this doesn't solve all problems, but it does provide a middle ground between flat keyfiles and rolling your own daemon.