tunneling through an intermediate host
I have [SuSE] machines at home and at work. I'd like to be able to connect to my machine at work from home and use X-based applications, copy files etc. But from home I have to login to a gateway machine at work and from there I can connect to my own machine. This is done by our administrators for security reasons. The login to the gateway is via ssh. Is there some way to set up a connection from my home machine through the gateway to my work machine that makes the gateway become invisible? So I can run programs that open connections from my home machine to my work machine or vice-versa? I know about the -X option of ssh for example, but setting that on the connection from home to the gateway and again from the gateway to my work machine doesn't seem to allow me to run X clients on my work machine and display them at home. Pointers to any useful resources would be welcome as well as direct suggestions. Thanks, Dave
On Tuesday 10 May 2005 11:39, Dave Howorth wrote:
I have [SuSE] machines at home and at work. I'd like to be able to connect to my machine at work from home and use X-based applications, copy files etc. But from home I have to login to a gateway machine at work and from there I can connect to my own machine. This is done by our administrators for security reasons. The login to the gateway is via ssh.
You can make ssh do this for you by using an ssh-agent (there's already one running for you in SuSE 9.2's KDE environment) (ssh-add your key to the agent before starting to ssh to remote machines). Then call ssh with -A -Y. From the manual page: -A Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file. Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connec~ tion. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. -Y Enables trusted X11 forwarding. This seems to work for me, allowing me to ssh from machine A to machine B, then againfrom machine B to machine C using the same keys (as held by my ssh-agent) to authenticate each connection. HTH, -- Bill
William Gallafent wrote:
On Tuesday 10 May 2005 11:39, Dave Howorth wrote:
I have [SuSE] machines at home and at work. I'd like to be able to connect to my machine at work from home and use X-based applications, copy files etc. But from home I have to login to a gateway machine at work and from there I can connect to my own machine. This is done by our administrators for security reasons. The login to the gateway is via ssh.
You can make ssh do this for you by using an ssh-agent (there's already one running for you in SuSE 9.2's KDE environment) (ssh-add your key to the agent before starting to ssh to remote machines). Then call ssh with -A -Y. From the manual page:
-A Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connec~ tion. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
-Y Enables trusted X11 forwarding.
This seems to work for me, allowing me to ssh from machine A to machine B, then againfrom machine B to machine C using the same keys (as held by my ssh-agent) to authenticate each connection.
HTH,
My problem is that I can log in from A to B and then from B to C but I can't then start an X application on C and view the resulting window on A. Admittedly I'm using passwords rather than agent forwarding but would that make any difference? Machine B is an OSF1 box and ssh -V gives ssh: SSH Secure Shell Tru64 UNIX 3.2.0 I don't know whether that affects things. It has different syntax for the options for one thing (+x and -x) instead of (-X and -x) and no notion of -Y that I can see. Cheers, Dave
Is there some way to set up a connection from my home machine through the gateway to my work machine that makes the gateway become invisible? So I can run programs that open connections from my home machine to my work machine or vice-versa?
A couple of options: 0. SSH to the gateway as usual, setting up a forwarded port to the SSH port of your internal machine. You shouldn't need to enable X forwarding on this first connection since it doesn't sound like you're actually running anything X from the gateway. Then start another SSH session, using X forwarding, on your home machine but connect to the localhost port that you forwarded to your internal machine. This should work but might be a little slow due to the SSH-inside-of-SSH encryption going on but it sounds like you were kind of doing that anyway. This next idea is a bit more work but is well worth it in my opinion because it becomes totally transparent once it's all setup. 1. If your work machine has unfettered access OUT of the network then it might be easier to setup something like OpenVPN from the work machine to connect to a OpenVPN listener on your home network. This works best when your home IP is static or is at least the same for long periods of time. e.g. I'm on a dynamic IP at home but I've had the same IP address for almost a year and a half now. Some ISPs will deliberately change your IP periodically so it really depends on your provider. Anyway, I run OpenVPN from a server at work that pings the tunnel about every 15 seconds to keep the udp connection marked as active and this allows me transparent access in both directions using NAT and some routing information. If this outgoing connection won't work for you for whatever reason then you can tell OpenVPN to run over TCP instead of UDP, use the first SSH connection you make to forward that TCP port to your home machine to the internal machine, and then start an SSH-forwarded OpenVPN connection directly between your home machine and your work machine and you'll have roughly the same thing accept that having to use TCP for the tunnel instead of UDP generally results in lower performance. Let me know if this sounds interesting to you and I'll be glad to help you work out the details. I'll just say that this setup has worked amazingly well for me for almost two years and I highly recommend it if your home IP is even remotely stable. Hope that makes sense.
mb1-knetdome wrote:
Is there some way to set up a connection from my home machine through the gateway to my work machine that makes the gateway become invisible? So I can run programs that open connections from my home machine to my work machine or vice-versa?
A couple of options:
0. SSH to the gateway as usual, setting up a forwarded port to the SSH port of your internal machine. You shouldn't need to enable X forwarding on this first connection since it doesn't sound like you're actually running anything X from the gateway. Then start another SSH session, using X forwarding, on your home machine but connect to the localhost port that you forwarded to your internal machine. This should work but might be a little slow due to the SSH-inside-of-SSH encryption going on but it sounds like you were kind of doing that anyway.
This sounds interesting, and it appears to work in my testing at work. I'll try it for real tonight. I didn't understand the description at first sight, so for anybody else who didn't either, here's an example of the command lines. Suppose the machines are called 'home', 'gateway' and 'work' and I want to start xeyes on 'work' and see the result on 'home': In one terminal: home$ ssh -L 2222:work:22 gateway SOME PASSWORD STUFF HERE gateway$ Then in another terminal: home$ ssh -X -p 2222 localhost MORE PASSWORD STUFF work$ xeyes and the eyes come up on my 'home' machine. Now I guess it's worth setting up the agent's properly so I don't have any password nonsense :) Thanks greatly.
This next idea is a bit more work but is well worth it in my opinion because it becomes totally transparent once it's all setup.
I think I prefer your first suggestion precisely because it isn't so transparent! I'd prefer to have a situation where the traffic between my home and the network is limited to just that I have explicitly enabled so far as possible. Or did I miss something? Cheers, Dave
1. If your work machine has unfettered access OUT of the network then it might be easier to setup something like OpenVPN from the work machine to connect to a OpenVPN listener on your home network. This works best when your home IP is static or is at least the same for long periods of time. e.g. I'm on a dynamic IP at home but I've had the same IP address for almost a year and a half now. Some ISPs will deliberately change your IP periodically so it really depends on your provider. Anyway, I run OpenVPN from a server at work that pings the tunnel about every 15 seconds to keep the udp connection marked as active and this allows me transparent access in both directions using NAT and some routing information.
If this outgoing connection won't work for you for whatever reason then you can tell OpenVPN to run over TCP instead of UDP, use the first SSH connection you make to forward that TCP port to your home machine to the internal machine, and then start an SSH-forwarded OpenVPN connection directly between your home machine and your work machine and you'll have roughly the same thing accept that having to use TCP for the tunnel instead of UDP generally results in lower performance.
Let me know if this sounds interesting to you and I'll be glad to help you work out the details. I'll just say that this setup has worked amazingly well for me for almost two years and I highly recommend it if your home IP is even remotely stable.
Hope that makes sense.
-- Dave Howorth MRC Centre for Protein Engineering Hills Road, Cambridge, CB2 2QH 01223 252960
0. SSH to the gateway as usual, setting up a forwarded port to the SSH port of your internal machine. You shouldn't need to enable X forwarding on this first connection since it doesn't sound like you're actually running anything X from the gateway. Then start another SSH session, using X forwarding, on your home machine but connect to the localhost port that you forwarded to your internal machine. This should work but might be a little slow due to the SSH-inside-of-SSH encryption going on but it sounds like you were kind of doing that anyway.
This sounds interesting, and it appears to work in my testing at work. I'll try it for real tonight.
Great, I really didn't explain it very well but it looks like you figured out well-enough what I meant to convey. Anyway, hope it worked for you when you tried it for real. Khan St. Preest
Dave Howorth wrote:
mb1-knetdome wrote:
Is there some way to set up a connection from my home machine through the gateway to my work machine that makes the gateway become invisible? So I can run programs that open connections from my home machine to my work machine or vice-versa?
A couple of options:
0. SSH to the gateway as usual, setting up a forwarded port to the SSH port of your internal machine. You shouldn't need to enable X forwarding on this first connection since it doesn't sound like you're actually running anything X from the gateway. Then start another SSH session, using X forwarding, on your home machine but connect to the localhost port that you forwarded to your internal machine. This should work but might be a little slow due to the SSH-inside-of-SSH encryption going on but it sounds like you were kind of doing that anyway.
This sounds interesting, and it appears to work in my testing at work. I'll try it for real tonight. I didn't understand the description at first sight, so for anybody else who didn't either, here's an example of the command lines. Suppose the machines are called 'home', 'gateway' and 'work' and I want to start xeyes on 'work' and see the result on 'home':
In one terminal: home$ ssh -L 2222:work:22 gateway SOME PASSWORD STUFF HERE gateway$
Then in another terminal: home$ ssh -X -p 2222 localhost MORE PASSWORD STUFF work$ xeyes
and the eyes come up on my 'home' machine.
I tried this from home and it didn't work :( Good to know Murphy's alive and well. My problem was passwords. When I do the second ssh, it asks me for the password for 'dave@localhost'. I tried my password on that home machine, my password on the gateway machine (different username, btw), my password on my work machine and no password at all. None worked. Anybody have any idea what I'm doing wrong? Thanks, Dave
On Thursday 12 May 2005 12:19, Dave Howorth wrote:
Dave Howorth wrote: <snip>
In one terminal: home$ ssh -L 2222:work:22 gateway SOME PASSWORD STUFF HERE gateway$
Then in another terminal: home$ ssh -X -p 2222 localhost MORE PASSWORD STUFF work$ xeyes
and the eyes come up on my 'home' machine.
I tried this from home and it didn't work :( Good to know Murphy's alive and well. My problem was passwords. When I do the second ssh, it asks me for the password for 'dave@localhost'. I tried my password on that home machine, my password on the gateway machine (different username, btw), my password on my work machine and no password at all. None worked. Anybody have any idea what I'm doing wrong?
Then in another terminal: home$ ssh -X -p 2222 <workuser>@localhost ---------------- I guess at work you don't user the same user as on the home machine (dave)? Jerry
Thanks, Dave
On Tuesday 10 May 2005 02:39 am, Dave Howorth wrote:
I have [SuSE] machines at home and at work. I'd like to be able to connect to my machine at work from home and use X-based applications, copy files etc. But from home I have to login to a gateway machine at work and from there I can connect to my own machine. This is done by our administrators for security reasons. The login to the gateway is via ssh.
Why can't you just ssh directly home? Is this so called administrator under the impression that an outbound ssh connection is a threat but a web browser connection is not? And if outbound ssh is a threat (which of course means they don't trust their own employees) why on earth would he allow you to log into a gateway and do it that way? And assuming that you can browse the web from work, why not just make your home ssh server at home run on some convenient port such as 443 which the mighty administrator can't reasonably block as it is used for ssl web browser sessions? -- _____________________________________ John Andersen
John Andersen wrote:
On Tuesday 10 May 2005 02:39 am, Dave Howorth wrote:
I have [SuSE] machines at home and at work. I'd like to be able to connect to my machine at work from home and use X-based applications, copy files etc. But from home I have to login to a gateway machine at work and from there I can connect to my own machine. This is done by our administrators for security reasons. The login to the gateway is via ssh.
Why can't you just ssh directly home? Is this so called administrator under the impression that an outbound ssh connection is a threat but a web browser connection is not?
I'm not sure I follow your idea here. I want to contact my work machine from home. Are you suggesting I login to the gateway, then to my work machine and then use ssh to log back in to my home machine? I'm not familiar enough with ssh to understand how that lets me start X clients on my work machine that use my home machine for the display. What are the appropriate ssh command line options - I get confused about them.
And if outbound ssh is a threat (which of course means they don't trust their own employees) why on earth would he allow you to log into a gateway and do it that way?
I don't think any sysadmin/company in his/her/its right mind trusts its employees absolutely :) Most of the blocks at our site are to protect the network from attacks and legal liability and to protect the users from themselves. Some of the students and perhaps others don't understand the consequences of some of the things you can do on the net.
And assuming that you can browse the web from work, why not just make your home ssh server at home run on some convenient port such as 443 which the mighty administrator can't reasonably block as it is used for ssl web browser sessions?
Cheers, Dave -- Dave Howorth MRC Centre for Protein Engineering Hills Road, Cambridge, CB2 2QH 01223 252960
participants (5)
-
Dave Howorth -
Jerry Westrick -
John Andersen -
mb1-knetdome -
William Gallafent