Re: ssh-agent security questions

From: Richard E. Silverman (res_at_qoxp.net)
Date: 11/19/04

  • Next message: Darren Tucker: "Re: fatal: Read from socket failed: Connection reset by peer" 
    Date: 19 Nov 2004 02:01:08 -0500

    >>>>> "ekb" == ekb <mail4ekb-usenet93d283ddux3*at*yahoo.com> writes:

        ekb> By connecting to a non-trusted machine, using my normal public
        ekb> key for authentication and running ssh-agent, do I put my private
        ekb> key at risk to a blackhat system operator? Is there a way that
        ekb> he could, by reading the memory of his machine, gain access to my
        ekb> private key?

    Not directly, no. The agent never gives out private keys; the agent
    protocol does not include such a request. It accepts requests like, "sign
    this data with key foo," or "encrypt this data with key bar."

    However, there are risks. Agent forwarding to a compromised host puts the
    use of your private key at the disposal of an attacker for the duration of
    the connection. He could connect to another host to which you have access
    via public-key authentication. It should not give him the means to make
    later connections, though, since the SSH userauth protocol is designed to
    guarantee liveness; it requires the client to sign unpredictable data
    which are bound to the current connection. Also, access to the agent
    would allow chosen-plaintext attacks on your key.

    Some agents have the feature of prompting the user each time a key is used
    by some agent forwarding client (e.g. the OpenSSH agent with "ssh-add
    -c"). This is a good feature to use if you're worried about agent
    hijacking.

        ekb> I have tested connecting to the non-trusted machines with both
        ekb> rsa-authentication and password authentication and found that the
        ekb> key forwarding works in both cases.

    Agent forwarding is entirely separate from user authentication.

        ekb> Does this mean that my private key is "cached" on the remote
        ekb> non-trusted machine or is the 2nd leg authentication handled
        ekb> through a secure communication process back to my trusted client
        ekb> machine?

    The latter. 

    -- 
  Richard Silverman
  res@qoxp.net
  • Next message: Darren Tucker: "Re: fatal: Read from socket failed: Connection reset by peer"