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)

<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)

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)