1. Forum
  2. Usenet
  3. COMP.SECURITY.SSH

  • Public Key Authentication With SSH Proxy (MITM)

    From michaelmathisjr@gmail.com@21:1/5 to All on Fri Nov 22 23:26:32 2019
    Hi,

    I have enabled SSH inspection on a firewall. I am able to SSH successfully to a server with password authentication; however, when I use public key authentication, it fails.

    Originally, I thought that would be expected, as the proxy doesn't have the private key of the client. However, I was looking at the SSH RFCs and the secure transport layer should be established independent of the authentication method, so I would think
    this should be technically possible.

    I would guess that the problem has to do with the data integrity portion of the protocol; however, I am seeing in the SSH debugs that authentication is failing.

    Information on the firewall vendor sites suggests that this doesn't work in their implementation.

    Is SSH intercept technically possible with public key authentication? If not why? I have seen it mentioned on here that firewalls will break the session id, and it is part of the signature (see below.) However, I don't see why the firewall wouldn't
    pass on the same session ID.

    Is there any possible workaround? For instance disabling integrity checking (which doesn't appear to be possible in OpenSSH.)

    Thanks a bunch for the help!




    RFC 4252 SSH Authentication Protocol January 2006

    The value of 'signature' is a signature by the corresponding private
    key over the following data, in the following order:

    string session identifier
    byte SSH_MSG_USERAUTH_REQUEST
    string user name
    string service name
    string "publickey"
    boolean TRUE
    string public key algorithm name
    string public key to be used for authentication

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Tatham@21:1/5 to michaelmathisjr@gmail.com on Sat Nov 23 08:48:56 2019
    <michaelmathisjr@gmail.com> wrote:
    I have enabled SSH inspection on a firewall.

    In less euphemised language: your firewall is deliberately, under your
    own control, performing a MITM attack against SSH connections passing
    through it?

    I am able to SSH successfully to a server with password
    authentication; however, when I use public key authentication, it
    fails.

    Good! That is an intentional feature of SSH public key authentication,
    and it's always reassuring to hear that it's working as designed.

    The signature created by the client during public key authentication
    has to be a signature on some particular data. To prevent replay
    attacks, it has to be different data every time. But instead of the
    server sending a challenge of its choice, the protocol design instead
    arranges that the client signs the 'session id', which is a by-product
    of the key exchange phase and is a secret known only to the two
    endpoints of the connection.

    So, if you MITM a connection that uses PK auth, then your key
    exchanges with the client and server will generate different session
    ids. During authentication, the client sends you a signature on
    *their* session id, but that - on purpose - is not enough information
    for you to produce a matching signature on the *different* session key
    that you share with the server.

    Is there any possible workaround? For instance disabling integrity
    checking (which doesn't appear to be possible in OpenSSH.)

    If there is, then it's a bug in the protocol!

    Remember that everybody involved in the design and implementation of
    SSH is specifically aiming to *prevent* the thing you're asking for
    help doing. If we knew of a hole like that, we'd be busy *fixing* it,
    not documenting it carefully for your benefit.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From michaelmathisjr@gmail.com@21:1/5 to michael...@gmail.com on Sun Nov 24 22:50:34 2019
    Simon,

    Thank you for the quick response. Yes, in this case we are adding a rule to allow SSH to the internet on our corporate firewall for the purpose of administering VMs on a public cloud. We received a mandate to do SSH decryption for the purpose of
    blocking SSH port forwarding.

    Early on, it seemed to me that we could potentially make this work by generating key-pairs and both distributing them to the developers and also installing them in the firewall. Based on your response, it seems to me now that even that would be
    impossible, as the signature is over the session id. From a security perspective, it makes sense. If my key pair were stolen, someone could pretend to be me; however, they could still not eavesdrop on my conversations with a 3rd party.

    Thank you again.
    -Michael


    On Friday, November 22, 2019 at 11:26:34 PM UTC-8, michael...@gmail.com wrote:
    Hi,

    I have enabled SSH inspection on a firewall. I am able to SSH successfully to a server with password authentication; however, when I use public key authentication, it fails.

    Originally, I thought that would be expected, as the proxy doesn't have the private key of the client. However, I was looking at the SSH RFCs and the secure transport layer should be established independent of the authentication method, so I would
    think this should be technically possible.

    I would guess that the problem has to do with the data integrity portion of the protocol; however, I am seeing in the SSH debugs that authentication is failing.

    Information on the firewall vendor sites suggests that this doesn't work in their implementation.

    Is SSH intercept technically possible with public key authentication? If not why? I have seen it mentioned on here that firewalls will break the session id, and it is part of the signature (see below.) However, I don't see why the firewall wouldn't
    pass on the same session ID.

    Is there any possible workaround? For instance disabling integrity checking (which doesn't appear to be possible in OpenSSH.)

    Thanks a bunch for the help!




    RFC 4252 SSH Authentication Protocol January 2006

    The value of 'signature' is a signature by the corresponding private
    key over the following data, in the following order:

    string session identifier
    byte SSH_MSG_USERAUTH_REQUEST
    string user name
    string service name
    string "publickey"
    boolean TRUE
    string public key algorithm name
    string public key to be used for authentication

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)