There are a large number of reasons why this can happen:
- 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.
- Out of date info The host key for Gitlab may have changed and they simply forgot to update that help page accordingly.
- 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.
