5
$\begingroup$

I'd like to use a password-based system on a remote host (accessed via SSH) without having to copy-and-paste the password and without storing it on disk. Using the system with some other form of authentication is not an option.

One possible solution is to talk directly to ssh-agent and have it sign a constant token and then use, say, the signature's base64-representation as the password. This password can always be re-generated, assuming access to the private key and knowledge of the token.

https://gist.github.com/mprymek/10415576 shows that this technique is being used in the wild.

  1. Is this approach (deriving a password from a signature) cryptographically sound?

  2. Is this approach secure? For example, when SSH agent forwarding is used, is the signing request and response (exchanged between remote host and local ssh agent) safe from eavesdropping?

EDIT: draft-ietf-secsh-agent-02 section 4.2 says that forwarding happens through an SSH channel, and the abstract of RFC 4254 says that "channels are multiplexed into a single encrypted tunnel" which I believe means that agent forwarding is fully encrypted.

$\endgroup$
7
  • $\begingroup$ This is not an answer, but not all signature algorithms will always generate the same signature for the same message. $\endgroup$
    – otus
    Oct 14, 2014 at 20:19
  • $\begingroup$ @otus Interesting, I wasn't aware of that. I was planning to use it with RSA only, which I believe provides deterministic signatures. $\endgroup$
    – julian37
    Oct 14, 2014 at 23:13
  • 1
    $\begingroup$ It depends on if it is using PKCS#1 v1.5 padding or OAEP. The first will give deterministic signatures, but is generally considered to be broken. OAEP is provably secure, but has randomized signatures. $\endgroup$ Oct 15, 2014 at 0:38
  • $\begingroup$ @TravisMayberry Thanks for the additional information. draft-ietf-secsh-agent-02 says that signing "normally performs the raw private key operation" which I understand to be signing without any padding, and my experimental tests (against OpenSSH_6.2p2) seem to confirm this. $\endgroup$
    – julian37
    Oct 15, 2014 at 0:58
  • 1
    $\begingroup$ @TravisMayberry You're right. Looking at ssh-rsa.c (search for ssh_rsa_sign) they appear to be using RSASSA-PKCS1-v1_5. $\endgroup$
    – julian37
    Oct 15, 2014 at 10:38

1 Answer 1

3
$\begingroup$

Is this approach (deriving a password from a signature) cryptographically sound?

Not in general. There are signature algorithms that are completely deterministic and signature algorithms that aren't. With the latter kind you would be unable to reproduce the password later.

With a deterministic algorithm, yes, the basic idea of using the signature as a password is sound (assuming no attacker can get the signer to sign the same token in some other situation). If it wasn't secure, that would mean the attacker had some way to produce the same signature, which would mean the signature algorithm itself would be broken.

Note that rather than sending a token for the client to sign, an SSH v1 server actually encrypts a token, sends it to the client and stores a hash. The client must decrypt the token and reproduce the same hash in its response. (See section 2.3 of the document you linked.) This is likely why the linked program talks about 160-bit passwords.

A similar argument as above makes this secure: to know the hash an attacker has to either know the original token generated by the server or be able to decrypt the challenge (which they can't do without the key, unless the encryption algorithm is broken).

Is this approach secure? For example, when SSH agent forwarding is used, is the signing request and response (exchanged between remote host and local ssh agent) safe from eavesdropping?

As for whether that's safe from eavesdroppers... yes, if you assume they are outside the systems involved. An attacker with sufficient control over the final destination machine could eavesdrop the original challenge generation. An attacker with sufficient control over the source machine where you authenticate could similarly eavesdrop the response generation.

I'm not entirely sure whether an attacker on the middle machine would be able to do the same, but I believe so. As I understand the forwarded traffic passes unencrypted from ssh to sshd and is only encrypted between the hosts. That's (one reason) why some people have suggested using more complicated layered ssh connections instead of agent forwarding.

$\endgroup$
2
  • 2
    $\begingroup$ "SSH server actually encrypts a token"? No. The section 2.3 which you refer to describes agent usage with the SSH v1 protocol only; it predates SSH v2 by a few years. According to RFC 4252 section 7, SSH v2 changed this to a regular sign-verify – I'm guessing it was to allow sign-only algorithms such as DSA to be used (RFC 4253 section 6.6), where SSH v1 was limited to RSA only. $\endgroup$
    – user1686
    Aug 4, 2015 at 19:59
  • $\begingroup$ @grawity, thanks, fixed to mention this difference. Regardless of which version of ssh and thus challenge-response protocol is used, the conclusion should be the same. Right? $\endgroup$
    – otus
    Aug 5, 2015 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.