1

I'm running GitLab and serving git repositories over SSH from GitLab's internal SSH-server. It works just like Github: users adds their public key in a web page and are able to use SSH after that.

I want to restrict access to this server from the Internet while having it completely open on our local network. Is there any way I can set up a SSH-server in front of GitLab that

  1. Authorize users against a whitelist (e.g. ~/.ssh/authorized_keys)
  2. Forwards authorized traffic to my GitLab server

This is quite easy to do with HTTPS-traffic and client certificates using HAProxy, but I can't find any way to achieve the same with SSH and public keys.

Improve this question
2
  • what do you mean with "open access on your local networks"? I'm pretty intimate with git, and I really can't see a use case for anything beyond anonymous cloning. And if you want that, why not just have a hook that simply updates a second server that offers local read-only access? Also, what's the advantage of being able to anonymously clone via SSH instead of HTTPS? it's not like you'd want to enable people to anonymously push…
    – Marcus Müller
    Commented Jan 28, 2017 at 18:53
  • "Open access" means "don't use the whitelist for authorization when source ip is local network". Use case for non anonymous cloning is private repositories. What I can do is set up a local forward tunnel with openssh, but that seems kinda hack, and it doesn't let me filter traffic based on IP.
    – gogstad
    Commented Jan 28, 2017 at 22:42

3 Answers 3

Reset to default
0

I think the concept you're looking for here is ssh bastion.

user-> ssh-bastion -> gitlab

Deploying user public keys from your gitlab server to your bastion will be something of a trick. Perhaps a cron job and rsync? Note: there will be some client setup, but I think it is 3 lines in the client side ~/.ssh/config

Another approach is to create firewall (or security group if you were to deploy in the cloud) rules to whitelist public IPs of your users. This assumes your users have static IPs. This adds a maintenance task of maintaining that whitelist.

A third approach is to stand up a simple openvpn server and add another step for remote users with dynamic IPs. This adds another layer of security by requiring vpn credentials + git keys. But now you're supporting a vpn server and vpn clients on each end node.

Improve this answer
3

Your use case of shielding your GitLab server from outside traffic is commonly solved with a firewall. A firewall can easily be installed locally on the GitLab that will block all incoming traffic except the traffic from the local network. Also a firewall can be installed in front of the GitLab server.

This traffic should still be authenticated using the normal ssh keys used by GitLab.

Improve this answer
0

The whitelisting you described can be done with the AllowUsers directive in sshd_config. There's no need for a firewall, it adds unneccessary complexity.

Improve this answer
1
  • AllowUsers means you have to add users in two places. And in general "no need for a firewall" is probably bad security advice. Security in depth means many protections at many levels. Firewalls are typically a great addition to any given security stance.
    – jorfus
    Commented Apr 24, 2018 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .