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.

  • 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… 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
    Jan 28, 2017 at 22:42

3 Answers 3


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.


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.


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.

  • 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
    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 .