Is piping a `ssh-agent` signed message as a password secure?

Question

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 combined¹ 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?

¹ 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 or 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 authorized_keys database.
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]

                          Use SIGNATURE as 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...

edit I wrote a small Python script for this, ssh-agent-sign

Answer 1

It's no less secure than entering a password over SSH to decrypt the container.

Whatever decrypting a container on a remote system is secure at all is completely different problem.

Answer 2

Here's my thoughts so far what an attacker could do:

• Server-only attacks:
  • Agent: Obtain MESSAGE and connect to the ssh-agent's socket to obtain SIGNATURE. Can be mitigated by ssh-add -c, -x or -t
  • Both: Eavesdropping
  • Both: ... most things that would work locally, e.g. wrap the passphrase prompt, brute force the container passphrase (Agent method can easily chose a more complex one, while the private key passphrase can remain rather easy); cold boot attacks, or reading the passphrase from a running system's memory while the container is mounted
• Client-also attacks:
  • Passphrase: Keylogger
  • Agent: Obtain the unencrypted private key

Anyway, here's an actual implementation for obtaining a signature: ssh-agent-sign (disclaimer: I wrote it)

Answer 3

Heh, I actually had the same idea for encrypting data on remote machines when I stumbled upon your question. I do not understand why you need to combine MESSAGE and SIGNATURE to create PASSWORD. Isn't SIGNATURE enough? If it isn't MESSAGE won't help. As I see it, the first thing that needs to be established is whether a signature is as strong a key as a private key. To establish that, a few things need to be determined:

• Does the signature have the same entropy as the private key? - The signature length is always the same size as the key used. So with respect to key length the amount of entropy is unaffected.
• Is a signature just as random as the key that was used? (I actually don't know)
• Does the content of MESSAGE have any effect on the randomness of SIGNATURE? (Don't know that either)

Regarding MESSAGE: I think it would be wise to make it as random as possible using openssl rand (though, maybe not).

I do not see any problem with the protocol itself

A tip: Instead of piping the signature directly to something that you want to encrypt, you could decrypt the actual key (KEY) that should be used. This way you can allow multiple signatures to decrypt the same data (by saving the actual key multiple times encrypted with different signatures). So the protocol would look something like this.

Client:                   Server:
>ssh-add SECRET
>ssh -A server            
                          Locate keyfile for available signature
                          Ask ssh-agent to sign MESSAGE from keyfile with SECRET
ssh-agent returns SIGNATURE
                          Use SIGNATURE to decrypt PASSWORD from keyfile
                          Use PASSWORD to decrypt the actual data

I think I'll give it a go and try implementing this using socat and bash only, shouldn't be that hard :-)