SSH: Key authentication, host keys and security implications

The last few posts have been dealing with the ssh related security aspects to consider while putting together eBrainPool. Erle has done a good job of answering a few of the questions I raised in the post SSH integration: Points to ponder and I thought I'll make an attempt to present my understanding (correct me if I'm wrong :) ) on how public key authentication takes place between the client and server,where the server host key fits in and more importantly why it is necessary to keep these distinct and as safe as possible.

Step 1. The client wishes to connect to the server. The server's host key is verified by the client and the user is asked if this key should be added to the known_hosts if it does not exist there already.

Step 2. Public key based authentication dance between the client and server. The following is an excerpt of a chat between a libssh developer Milo who has been graciously helping me get the server together. Here he is explaining how public authentication works between client and server.

> 1:09 PM the client sends its pubkey key and signs it with it's privkey
> 1:10 PM me: ah ok...and this gets tested by the server (on sshd in the authorisedkeys file) correct?
> Milo: well it could be yes
> 1:11 PM actually, libssh server just tests the validity of the signature
> and the function my_pubkey_auth() would compare it against authorized_keys
> 1:12 PM when (signature_state == SSH_PUBLICKEY_STATE_VALID), it just says "you are who you say you are"
> 1:13 PM after that, the second phase is to check if the user is authorized to connect</em>

..so there we have it, public key authentication transaction between the client and the server. The client sends a public key signed with his private key, the server verifies this signature and makes sure the person is who they say they are and then goes on to check within it's authorized_keys (or some other means) if this particular user should be granted access.

Now based on the above knowledge and the knowledge that the user authentication keys are the same ones being used by eBrainPool and openssh and eBrainPool is being launched as the same user and not a distinct sandboxed user, it is quite easy to see how we can get access and ssh in to a host without her authorization. Since the client sends out a public key signed by the user's private key, if the server stores this pubkey/private key value in theory it should be possible for him to connect back to the openssh server on the users end. This is how this kind of an attack could possibly be executed

  • An eBrainPool user A would connect to a remote eBrainPool user B and request an application be executed.

  • An ssh session gets established, user A checks the known_host information of the server at the other end. Sends out his public key signed with the private key.

  • User B has malicious intents, he stores this pubkey / private key information (not sure if this would be easy to do or makes sense since this would be encrypted too but for now considering this can be done)

  • User B then at a later point in time tries to log in to User A's standard openssh and passes along the previous stored key i.e. the pubkey signed with User A's private key. 

  • User A's server would presume this is User A himself trying to connect to his own system and grant access

....and this time he will have full access to the users ssh account and not just an eBrainPool account.

Therefore as I understand it, it is very crucial to know and trust the server you are connecting to and in our case it becomes imperative that we keep all of these keys and the eBrainPool account itself as distinct from the main users account. IMHO, based on the above line of thought (which maybe inaccurate and needs to be vetted by a security guru) it is best if we

a) have eBrainPool itself run as a different user (preferably a temporary user if possible)

b) Do not use a users openssh public key and private key.

c) Do not use the system host keys used by openssh itself (i.e. what we usually find in /etc/ssh)

d) Use FUSE to make sure that even within a proper eBrainPool session the user can't get access to data other than his own and on his device.

Disclaimer: Forgive me, for I know not what I speak :) I am not a security guru and am not sure if what I am saying above makes any sense at all. (I am generally not sure if anything I say makes any sense at all but that's for another blog someday ;) ) On the matter at hand I do plan to discuss this on the libssh/openssh forums sometime and see what they have to say about this.

Previous Post Next Post