Custom publickey authentication

Question

I'm working on a REST account management system over https that should support both username/password and username/publickey authentication schemes. I.e. when a user registers an account, they may chose to additionally upload their ssh public key; all subsequent requests would then not require a password anymore.

I wouldn't want to depend on the server having a filesystem for OpenSSH to store its keys on - this is why I can't simply have sshd running and have it deal with auth.

So, the plan is for the client to sign some message using the user's private key (i.e. openssl dgst -sha256 -sign ~/.ssh/id_rsa ...). The server, having the client's public key, would then verify that the expected message is correctly signed.

The question is now, what to sign? As far as I understand, OpenSSH uses a session identifier, which among others is based on the computed shared secret between the client and the server.

I don't want to invent my own crypto, so I was wondering if I could reuse the https connection shared secret for that. Or is this already considered "inventing my own crypto"?

Answer 1

The thing you want to guarantee here is freshness, so having the client sign some nonce - any nonce, as long as it's fresh - will work. Ideally, that signature should also be bound to the channel, but the signature and nonce are being transmitted inside the encrypted channel, so maybe that's enough.

Ideally, though, you're right, signing the TLS shared secret would accomplish both. I'm just not sure how easy that is to actually implement.

Using TLS client authentication would be better still, because TLS does all of this for you. Client certificates would be my first choice, but if you're hell-bent on using SSH keys, TLS raw public key authentication might do the trick.