17

Context

I am running Ubuntu Desktop as my primary machine, which I will call D. I want to connect to server S via ssh, but the firewall is blocking me.

I have access to server S, via a very cumbersome path, involving a Windows virtual machine and PuTTY. This makes working with this server extremely annoying: completely different environment, copy/paste does not work, I can not properly use my desktop while being connected to it (Alt-Tab is broken by the Virtual Machine) etc

I have verified that I can ssh from server S to my desktop machine D (the opposite from what I need).

Could I somehow initiate "port forwarding" or similar from the server, so that I can ssh to the server from my desktop?

Improve this question
3
  • 2
    Jump hosts... gotta love 'em!!!
    – RonJohn
    Feb 21, 2018 at 21:39
  • Possible duplicate of Tunnel SSH from A->B->C
    – muru
    Feb 22, 2018 at 2:32
  • @muru this is a different scenario, but of course related (it's about tunnelling after all!). In this case I want to fake D->S by abusing S->D
    – blueFast
    Feb 22, 2018 at 7:55

3 Answers 3

Reset to default
32

You can use the following command to set up an SSH tunnel from the remote server to your local machine:

$ ssh -f -N -R 1234:localhost:22 user@your_machine_ip

When the tunnel is set up, you can simply ssh to your remote server using the following command:

$ ssh -p 1234 user@localhost

Please note that you need to set up ssh keys for automatic login (no password prompt). If you want to create the SSH tunnel interactively, you can remove the options -f -N. For more info, man ssh.

Improve this answer
6
  • How does this tunnel through the Windows VM? (Where I work, there are multiple layers of firewalls and only a few ports are opened.)
    – RonJohn
    Feb 21, 2018 at 21:43
  • @RonJohn I believe this uses the fact that (for OP) ssh-ing from the server to the desktop works, so this sets up a tunnel from the server (port 22) directly to the desktop machine (port 1234) that can be used to connect to ssh on the server (which uses port 22). The windows VM is only used to set up the tunnel. (please correct me if I'm wrong)
    – pizzapants184
    Feb 22, 2018 at 2:06
  • @dangonfast In addition to the answer you might find the following document of value: spencerstirling.com/computergeek/sshtunnel.html
    – Pryftan
    Feb 22, 2018 at 2:27
  • @RonJohn The document I just linked to might help answer that question too, at least as far as multiple layers of firewalls etc. goes (if memory serves me right - it's been a very long time that I've read it.. I just remembered having the link from years ago).
    – Pryftan
    Feb 22, 2018 at 2:29
  • 1
    @pizzapants184 indeed, that was my starting point: ssh from S -> D, so I want to abuse this to efffectively do D -> S, even though that does not direclty work. Why is the network configured like that, is something that escapes me. It could be intentional or a misconfiguration, but as long as it works for me ...
    – blueFast
    Feb 22, 2018 at 5:38
5

If you are running a newer version of OpenSSH (7.3+) then you can use ProxyJump which bakes everything together magically:

ssh -J windows_machine remote_server

Which in your ~/.ssh/config looks like:

Host remote_server
        HostName remote_server
        ProxyJump windows_machine
        User myname

ProxyJump supports full SSH syntax, so if you are jim on windows_server and it uses port 2222 for ssh. remote_server is at IP 192.168.0.110 from the windows_server then you can write:

Host remote_server
        HostName 192.168.0.110
        ProxyJump jim@windows_machine:2222
        User myname

And still just run ssh remote_server to get there.

If you are running an older version of SSH, use ProxyCommand - this allows you to tell SSH to first run a command to establish a proxy connection, before running the actual SSH command.

ssh -o ProxyCommand='ssh -W %h:%p windows_machine' remote_server

This uses the SSH -W option, which is shorthand for the more arcane netcat syntax.

Note that, as when you run ssh remote_server you are now on the windows_machine you need to ensure that you use the IP of the remove_server from the jump box rather than the IP from your machine - these may well be the same.

You can then add this directive to your ~/.ssh/config file:

Host remote_server
  HostName remote_server
  User myname
  ProxyCommand ssh -W %h:%p windows_machine

This means that if remote_server is a different machine as seen from windows_machine then you can put that in the config and still just use ssh remote_server.

Improve this answer
5
  • 1
    This is a much better answer.
    – Robert Riedl
    Feb 22, 2018 at 12:43
  • While useful, this doesn't answer the question being asked. OP states that they cannot SSH from D->S (what they want), but they can SSH from S->D. There is no ssh proxies in between (there is instead the windows virtual machine, probably being accessed by RDP).
    – mbrig
    Feb 22, 2018 at 16:40
  • @mbrig indeed. I have not tried this solution, but I would be surprised if it works: I am firewalled from D -> S
    – blueFast
    Feb 23, 2018 at 9:05
  • But you say you can get to the windows machine - from that I understood that it can act as a jump box between you and the other machine.
    – Boris the Spider
    Feb 23, 2018 at 9:38
  • 1
    I can login to the windows machine with a propietary tool (VMWare Horizon). I never said I can ssh to it. I even tested this before posting this question by installing the Putty companion ssh server (I forgot the name), but my tests failed. I assume ssh is firewalled to the windows subnet too.
    – blueFast
    Feb 24, 2018 at 20:35
1

Rather than trying to circumvent things and create a convoluted path, can't you just ask for SSH from your desktop to the server to be allowed? If you have the need for it and you should be accessing the server I can't see why you would have the request refused.

Improve this answer
5
  • Care to explain the downvote? The question is "How to ssh to a server which I can not directly reach?" so my answer to have a firewall rule put in place to allow it is valid. It's also the proper way to go around it according to good security practice.
    – Solarflare
    Feb 22, 2018 at 9:17
  • I am in my first week of a three month contract of a big corporate customer. I have not been given a laptop (I use mine), and barely a desk. I got dozens of credentials to use the different services, and I am barely managing to juggle the whole thing. What I want to do is not a hard requirement to perform my work: I can work in the VM, and that's what my boss will tell me if I start asking funny questions. Or he will point me to the Help Desk which will kick the can down the road for the next couple of weeks / months.
    – blueFast
    Feb 22, 2018 at 9:33
  • For me working in the VM will easily mean 50% productivity loss, so I want to avoid it as much as possible. Still, I love this gig!
    – blueFast
    Feb 22, 2018 at 9:34
  • 1
    I can understand that. In my experience 'big corporate customers' tend to get pretty upset when contractors circumvent firewalls and policies in order to do their work, even if it is for altruistic purposes. The fact that you can SSH from the server to your desktop says to me that either you not being able to do the reverse is an oversight or something that has been put in place for a specific purpose.
    – Solarflare
    Feb 22, 2018 at 9:53
  • 4
    This is the only real solution if you want to avoid the risk to get fired for circumventing policies... At the very least, talk to the responsible persons before using Khaleds solution so they know what you are up to.
    – Sven
    Feb 22, 2018 at 10:00

You must log in to answer this question.

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