12

I tried to log into my university's gitlab via SSH. As expected, I was warned that the host is not known. Therefore, I tried to find the SSH host key on the "current configuration" page in the manual. However, I found that the key does not match the key that SSH shows me on the first connect.

To demonstrate this, here you can find the respective "instance_configuration" page for gitlab.com. The RSA-SHA256 fingerprint is said to be

2fdd0c7dfa7d9381f847266c800eafc96f5866fe859c4f1cf87da885c82e333a

Using the script I found on this superuser post (or when connecting via SSH for the first time) I am told that the RSA-SHA256 for the SSH host is

ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ

which is

44e405bcf4e11ab5b846e58ba0bf6dabd23dcc9e367cae17cb0c91b5b3b3fc44

in hexadecimal (and hopefully matches what you see… or not).

My questions: Should'nt these be equal? Did I miss something? How can I verify that the SSH connection is secure?

  • 5
    How comes you think gitlab.com is the gitlab instance of your university? Pretty sure it's not. – deviantfan Jun 24 '18 at 11:18
  • 2
    @deviantfan That was just an example to illustrate what happened. – HerpDerpington Jun 24 '18 at 11:36
  • 2
    What makes you think they're not equal? Just because they're in differenct encoding doesn't mean they're different. – Nomad Jun 24 '18 at 15:01
  • 2
    @deviantfan: Sure, one should distinguish the instances. But if you try to log in into gitlab,com, you get a ECDSA key fingerprint f1:d0:fb.... Where as the web page say that the ECDSA key fingerprint is be:bc:6f.... The OP asks about the difference. – mentallurg Jun 24 '18 at 15:33
  • 4
    For what is worth, I see the same fingerprints that you see, maybe that page is just out of date. You should probably open an issue on GitLab. – smeso Jul 4 '18 at 19:00
3
+50

There are a large number of reasons why this can happen:

  1. Hosting location. Gitlab can be downloaded and hosted elsewhere. The host keys posted on gitlab's page don't mean anything if your university is hosting their own version of gitlab. In that case you would never see gitlab's host key - you would see the host key for your university server, and the difference would be meaningless. You would have to ask the university what their host key is, and you are very unlikely to get an answer from them.
  2. Out of date info The host key for Gitlab may have changed and they simply forgot to update that help page accordingly.
  3. MitM Someone could be executing a MitM attack against your computer and has redirected traffic from gitlab to their own malicious server.

I figure option #1 is worth mentioning because it's not quite clear if your University's gitlab page is hosted with gitlab or your university. It sounds like it is gitlab hosted, but it isn't necessarily (obviously the repo URL should make that clear).

The possibility of MitM

Out of all three of these options, #3 is by far the least likely. A successful MitM attack in this case can be both difficult and has little real benefit (for an attacker), so much so that it wouldn't even occur to me to consider it under normal circumstances. So unless you are trying to connect to a remote gitlab repository so you can transfer up state secrets, you're probably just dealing with options #1 or #2.

You can also try to verify the likelihood of MitM by checking the IP address that of the server you are connecting to and trying to figure out if it belongs to gitlab. Gitlab does have a (probably also old) list of their ip addresses:

https://gitlab.com/gitlab-com/infrastructure/issues/434

No guarantees of a match even for a valid gitlab connection because of the possibility of out-of-date docs. Also no guarantees because someone running a successful MitM could possibly (depending on the details) also spoof an IP address.

Most likely scenario

Regardless, MitM is (IMO) very unlikely, and as a result I would just do your thing. You should be able to find out soon enough if there is a problem. Presumably you'll connect to the gitlab server, find the files you are expecting to find, copy up some stuff of your own, and then will be able to verify with whoever you are collaborating with that they received a copy of your work. If so there is definitely nothing to worry about.

In general, my experience suggests that few organizations bother publishing host keys for verification. Host keys certainly can be used to verify a server you have never connected to, but in practice I don't find that to be terribly common. I suspect this is primarily for the reasons I mentioned briefly above: I don't believe this to be a common attack vector and you can usually find out pretty easily if you are connected to the right server simply because there are almost always more parties involved to verify your results. As a result, I have most commonly used host key verification to detect when the server has changed than anything else, and I rarely (if ever) use it to verify a server on first connection.

1

TL;DR - I don't think this is anything to worry about at all, if you're still worried contact GitLab, I doubt anyone will be able to give you an answer here as we don't work there.


Personally, I don't think anybody here is going to help you. I believe your best chance of getting an answer here is to contact support at GitLab, that way you will get the correct answer.

As for whether the connection is secure, I don't think you have a reason to worry at all, as per Semso's comment if we're getting the same thing it's probably not a you issue if that makes sense.

I wouldn't worry too much about this, if you're still concerned contact GitLab I am sure they will be happy to help you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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