tl;dr: No, this will not work. The fact that the server knows your public key does not authenticate the server, even if you try to keep the public key secret.
This seems to be preventable if git uses the repository's deploy keys or the user's ssh-keys for encrypting the connection
Several issues here:
git
has no such concept as a "repository deploy key", this is part of GitLab. It appears to be simply a public key configured to allow read-only access to the repository, intended for use in code deployment (you may already understand this, but your question isn't fully clear to me).
- Using your
ssh
key to connect to something authenticates you by proving that you have the private key. It doesn't authenticate the server. This is why host keys are necessary.
ssh
keys aren't used to encrypt the connection, only to authenticated an already established secure connection (establishing the secure connection is a separate part of the ssh protocol)
Public keys are called public for a reason, you should never assume it to be private even if you just generated it to add to GitLab over HTTPS and don't use it anywhere else.
ssh
authentication involves sending the public key to the server to see if it is allowed (called "public key blob" in RFC 4252 section 7). This is done after establishing a secure connection so that it can't be intercepted, but that doesn't matter if the session was established with a malicious server. An impostor could simply reply with "Why yes, I will accept that key to authenticate that user!" and fool you into thinking it's the legitimate server. The only correct way to authenticate a server with ssh
is by using its host key.