There's an encrypted filesystem on a server I
ssh into using public key authentication. Since a forwarded ssh-agent can deterministically sign a message (see also the ssh-agent protocol section 2.6.2), I consider using a message stored on the server combined1 with its signature (using a private RSA key stored on the client via the forwarded
ssh-agent) as password piped to the encryption program to solve my question How to decrypt an encrypted container via ssh without entering a passphrase while requiring some client authentication? (but basically any password prompting application could be involved here) and then discarded again. But is this a good (=secure) idea? What kind of combination between message and signature should I actually use? Is there a need for using a different key pair than for the ssh authentication? Or am I trying to invent a triangular wheel?
1 Does combining the original message with the signature actually help in any way compared to simply using the signature alone? (Apart from entropy, but assume key stretching is applied anyway)
Here's a short summary of how SSHv2 public key authentication works:
sshd on the remote server expects the client's
ssh-agent to sign a predetermined message with its private key (that is not stored remotely) and the server can then verify it via the forwarded public key and check it against the user's
ssh-agent-forwarding now usually consists of connecting to a third PC. The intermediate PC generates the message, but asks the original client's
ssh-agent to sign it, without ever getting to know the private key itself. This very same signature instruction is what I want to use to obtain a "secret" (the signature, not the public key) that can be used as a password that is not stored anywhere (and cannot be reproduced on the client alone if the message-to-be-signed is stored only on the server) - no third PC involved, only the agent forwarding.
Here's an illustration of the process I intend to implement:
Client: Server: >ssh-add SECRET RSA KEY >ssh -A server <-- connect, forward agent (authentication does not need to use that specific secret key) Connect to the `SSH_AUTH_SOCK` unix socket and ask the client's ssh-agent to sign MESSAGE with SECRET RSA KEY (knowing only the respective PUBLIC RSA KEY to identify it) ssh-agent signs MESSAGE --> SIGNATURE [optionally verify SIGNATURE] Combine MESSAGE and SIGNATURE into PASSWORD, pipe that to the program and forget it.
To my understanding this implies the following:
Should the server be stolen, the thief would have to intercept the client signing
MESSAGE, otherwise they can't obtain
PASSWORD. Should the client be stolen, without
MESSAGE not even
SIGNATURE can be generated. Thus both server and client need to be stolen and the passphrase of the
SECRET RSA KEY be obtained - brute forcing of which would be just as annoying as brute forcing the original password itself...