Skip to main content

reverse proxy - Forward ssh connections to docker container by hostname

I have gotten into a very specific situation and although there are other ways to do this, I've kinda gotten obsessed with this and would like to find out a way to do it exactly like this:



Background




Say I have a server running several services tucked away in isolated docker containers. Since most of those services are http, I'm using an nginx proxy to expose specific subdomains to each service. For example, a node server is running on a docker container with its port 80 bound to 127.0.0.1:8000 on the host. I'll create a vhost in nginx that proxies all requests to myapp.mydomain.com to http://127.0.0.1:8000. That way, the docker container cannot be accessed from outside, except through myapp.mydomain.com.



Now I want to start a gogs docker container in such a way that gogs.mydomain.com points to the gogs container. So I start this gogs container with port 8000 bound to 127.0.0.1:8001 on the host. And an nginx site proxying requests to gogs.mydomain.com to http://127.0.0.1:8001 and it works well...



However, gogs being a git container, I would also like to access the repos like through git@gogs.mydomain.com:org/repo but that doesn't work with the current setup. One way to make that work would be to bind the port 22 of the container to the port 0.0.0.0:8022 on the host, and then the git ssh url can be something like git@gogs.mydomain.com:8022/repo.



(That doesn't seem to work; when I push to an origin with uri like that, git demands the password for user git on gogs.mydomain.com - instead of gogs.mydomain.com:8022 - but that's probably something I'm doing wrong and out of scope for this question, however, I would appreciate any diagnosis for that too)



Problem




My main concern is, that I want the ssh port :22 to be proxied just like I am proxying http ports using nginx; i.e. any ssh connections to gogs.mydomain.com get passed on to the container's port 22. Now I can't bind the container's ssh port to the host's ssh port because there is already an sshd running on the host. Also, that would mean that any connections to *.mydomain.com get passed to the container's sshd.






I want any ssh connections to:




  • mydomain.com host.mydomain.com or mydomain's IP address to be accepted and forwarded to the sshd on the host

  • gogs.mydomain.com or git.mydomain.com to be accepted an passed on to the sshd on the gogs container

  • *.mydomain.com (where * is anything other than the possibilities above) to be rejected




If it were http, I could easily make that work through nginx. Is there a way to do that for ssh?






(Also would like to go out on a limb and ask: is there a way to accomplish that with any tcp service in general?)



Any insights into the way I'm trying to do it here, are also welcome. I don't mind being told when what I'm trying to do is utterly stupid.







What I've already got in my mind:



Maybe I could share the sshd socket on host with the container as a ro volume? That would mean the sshd inside the container could pick up all connections to *.mydomain.com. Could there be a way to make the sshd inside the container reject all connections other than gogs.mydomain.com or git.mydomain.com? However, the sshd on the host will pick up all the connections to *.mydomain.com anyway including gogs.mydomain.com; so there would be a conflict. I dunno, I haven't actually tried it. Should I try it?

Comments

Popular posts from this blog

linux - iDRAC6 Virtual Media native library cannot be loaded

When attempting to mount Virtual Media on a iDRAC6 IP KVM session I get the following error: I'm using Ubuntu 9.04 and: $ javaws -version Java(TM) Web Start 1.6.0_16 $ uname -a Linux aud22419-linux 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:39:06 UTC 2009 x86_64 GNU/Linux $ firefox -version Mozilla Firefox 3.0.14, Copyright (c) 1998 - 2009 mozilla.org On Windows + IE it (unsurprisingly) works. I've just gotten off the phone with the Dell tech support and I was told it is known to work on Linux + Firefox, albeit Ubuntu is not supported (by Dell, that is). Has anyone out there managed to mount virtual media in the same scenario?

hp proliant - Smart Array P822 with HBA Mode?

We get an HP DL360 G8 with an Smart Array P822 controller. On that controller will come a HP StorageWorks D2700 . Does anybody know, that it is possible to run the Smart Array P822 in HBA mode? I found only information about the P410i, who can run HBA. If this is not supported, what you think about the LSI 9207-8e controller? Will this fit good in that setup? The Hardware we get is used but all original from HP. The StorageWorks has 25 x 900 GB SAS 10K disks. Because the disks are not new I would like to use only 22 for raid6, and the rest for spare (I need to see if the disk count is optimal or not for zfs). It would be nice if I'm not stick to SAS in future. As OS I would like to install debian stretch with zfs 0.71 as file system and software raid. I have see that hp has an page for debian to. I would like to use hba mode because it is recommend, that zfs know at most as possible about the disk, and I'm independent from the raid controller. For us zfs have many benefits,

apache 2.2 - Server Potentially Compromised -- c99madshell

So, low and behold, a legacy site we've been hosting for a client had a version of FCKEditor that allowed someone to upload the dreaded c99madshell exploit onto our web host. I'm not a big security buff -- frankly I'm just a dev currently responsible for S/A duties due to a loss of personnel. Accordingly, I'd love any help you server-faulters could provide in assessing the damage from the exploit. To give you a bit of information: The file was uploaded into a directory within the webroot, "/_img/fck_uploads/File/". The Apache user and group are restricted such that they can't log in and don't have permissions outside of the directory from which we serve sites. All the files had 770 permissions (user rwx, group rwx, other none) -- something I wanted to fix but was told to hold off on as it wasn't "high priority" (hopefully this changes that). So it seems the hackers could've easily executed the script. Now I wasn't able