SSH integration: Points to ponder

Hello everyone, it's been a busy few weeks with an IT consulting gig and other business. Trying to earn a living makes me wonder why I ever wanted to leave behind being a kid and grow up ;)...and then too I like to claim I'm older not necessarily wiser ;)

Of course developments with eBrainPool continue regardless of other happenings (breathe, eat and code :)). As reported earlier with regards the new integrated ssh server I've been working on, I've been seeing some strange behaviour wherein on some occassions libssh blocks in the function ssh_handle_packets. For some reason it keeps waiting infinitely for a condition even though there is data to be retrieved. I've been working with the libssh team to resolve this and deduce if this strange behaviour is because of something I did (I do have the effect ;) ) or if it's a bug in libssh. The entire discussion with the kind libssh devels helping us can be read at the following thread:

While this gets resolved I plan to continue on and integrate the server code with the main code base. Creating our own server gives us certain freedom on deciding how we handle keys,authentication,users,etc - which is why we wanted to build our own server in the first place. But as the wise Uncle Ben told Spiderman and the rest of us "With great power, comes great responsibility" ;) (hell any C/Assembly coder can relate to this ;) ), therefore we need to make certain SSH policy decisions and put thought to security and the overall functionality.

The following questions are currently floating around somewhere between Australia and India, in the mind of Erle and I and we thought we'd throw it open to discussion here:

  • Is the eBrainPool client going to be launched as a separate user?

  • Related to the above is if we are using the openssh keys of an existing user or generating new keys?

  • How are we storing these keys - as files like how openssh does? in a sqlite database? Will we have an authorised_keys file or something else?

  • A very crucial question is how do we distribute these keys to others in the mesh so they can authenticate with each other? At the current point we are relying on individuals manually exchanging their keys.

  • Apart from the user keys, there are similar questions about the host keys. Will we be using the system common host keys in /etc/ssh (ssh_host_dsa_key and ssh_host_rsa_key - will need root privileges)? or would we generate our own? How would these be distributed,stored,etc?

  • Does generating our own host key for non-root use by our server code somehow detriment security?

  • Currently, the ssh server script kicks in only when there is a request from a remote client to launch a new application. Only application traffic is therefore encrypted whereas all operations required for eBrainPool clients to be part of and determine who else is part of the mesh, retrieve user and software info,etc is all unencrypted. Is this the design we plan to stick with for now or should we keep all communication encrypted ?

We will be discussing more on all of the above and I'm looking forward to hearing any thoughts, suggestions,etc on how we should design the above.

Previous Post Next Post