Let's preface this by saying, that I'm indeed a very, very evil man, and the following does not correspond in any way shape or form to a real setup in the acutal realm of living breathing things. Nor should it. Ever.
So, we want a service on a machine - let's call it smelldap, for no particular reason - to be accessible. Only problem is, the machine sits behind a(ll the) firewall(s). It is, so to speak, inside a gated community, and our poor client is not allowed in. Particular cruelty has it, that this pitiful abandonee can't even see inside, can never meeting any of the elecronic denizins within that it so wants to authenticate. Such curelty cannot stand! Let us help the pitiful fella...
Meet sebastion the bastion host paragon of virtue in our stinky smelldap network. Heroically, sebastion will ssh to our client, who in turn, somewhat paradoxally learns a new trick and becomes a server. A server of the secure-shell variety. Ssh! Quiet!
On sebastion's way there, he will bring a gift, a remote port forward from smelldap, and thus the poor client will smell the free air of our oppressive community, not so gated anymore. Isn't that delightful!
To give that a measure of secuirty (Lipstick on a pig, I know), we will configure service users, no shell, no login, no password, no home, mind you, on both sebastion and the client. I lovingly call these users "hobos".
me@sebastion~$ useradd --no-create-home --system --shell /bin/false shobo # usermod -L shobo
me@client~$ useradd --no-create-home --system --shell /bin/false chobo
All packets from the hobos that don't go to either sebastion or the client or smelldap will be dropped as if underpayed UPS goons handled them. Mistreating the packages will be iptables "job", though - probably with comparable pay.
iptables --append OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# create a new chain
iptables --new-chain chk_hobo_user
# use new chain to process packets generated by the hobo user
iptables -A OUTPUT -m owner --uid-owner chobo -j chk_hobo_user # or --uid-owner shobo if you are on sebastion
iptables -A chk_hobo_user -p tcp --syn -d <smelldap_ip> --dport <allowed_port> -j RETURN
iptables -A chk_hobo_user -p tcp --syn -d <sebastion_ip> --dport <allowed_port> -j RETURN
iptables -A chk_hobo_user -p tcp --syn -d <client_ip> --dport <allowed_port> -j RETURN
# reject everything
iptables -A chk_hobo_user -j DROP # it like it's hot or delivered by UPS
# or ... REJECT like our poor client was
The client needs sshd running with options:
AllowTcpForwarding yes
GatewayPorts yes
PasswordAuthentication no
# Need /etc/ssh/authkeys_by_user/%u for authentication of service users that have no home directory
# The first two path are the defaults
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authkeys_by_user/%u
and be accessible from sebastion only via well kept, secured ssh-key-pairs, used exclusively for that purpose. None of that password rubbish.
me@sebastion~$ ssh-keygen -t rsa -b 4096 -o -a 100
...or something, paste the public (!) key to chobo's authorized_keys file
at client /etc/ssh/authkeys_by_user/chobo.
These keygen options are sensible defaults at the time of writing.
They offer a good balance of portability and security.
Future people might rather want to use elliptic curve ciphers.
You should look up what is secure when you do this.
And now for the grand (grant) finally, sebastion is up granting access to smelldap:
me@sebastion~$ sudo -u shobo \
ssh -i id_rsa -o UserKnownHostsFile=client_only -o StrictHostKeyChecking=yes -R '*:9999:smelldap:3269' chobo@client
You could bind it to 3269 as well, instead of 9999 on the client
but that would require privileges and we don't want hobos to have them.
Now, not without a measure of communism, smalldap's 3269 (nice!)
can now be accessed from any of client's IPs over the port 9999.
You might want to restrict that to a specific IP and use iptables for
further restrictions from outside IPs in the client network.
Autossh can help you keep that port forwad stable.
Enjoy!
And yes, 3269 is really an LDAP default port.