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"?