[HOWTO] - SSH Tunneling for Mac Users

[michaelsanford]

Scruffy, it sounds like what you need is a 'reverse forward' which is implemented by the -R option (instead of -L), which does something akin to passive FTP...

However, it sounds like the problem isn't the channel but the $DISPLAY setting. I had that problem and it was a real bugger to deduce.

Try cat /etc/sshd_config | grep #X11 and you should see something like
#X11Forwarding yes (no)
#X11DisplayOffset 10
#X11UseLocalhost yes

The first (no) indicates the default setting. Firstly, you need to make sure that first line is set to yes and uncommented. Secondly, if the displayoffset is set to 10, then your remote display will be :11 not :10

Also make sure that /etc/ssh_config looks like
Host *
ForwardAgent yes
ForwardX11 yes

Just a warning to note that the first file is sshd_config and the second is ssh_config

Try 'er our and let us know.

[scruffy]

Thanks Michael, but that's actually more or less the reverse of what I want to do. The ssh client is Linux box at school, and the server is my Mac at home. Problem with that - the school firewall lets nothing in. So, before I go home I would have to:
ssh -R 2222:127.0.0.1:22

Then when I get home, I can:
ssh -p 2222 -X localhost

which works, but it's dog slow, because I'm tunneling X11 over an ssh channel that's itself tunneled over an ssh channel the other direction - encrypting every mouse click twice.

   Linux                                      Mac
____________ ssh connection -> that way  ______________
|          |-----------------------------|            |
| 22 <----------------------------------------- 2222  |
|            ssh connection <- that way               |
|       -------------------------------------         |
| 6010 ---------------------------------------> 6000  |
|       -------------------------------------         |
|                                                     |
|          |-----------------------------|            |
|__________|                             |____________|

What I want to do is ssh from the Linux box at school to the Mac at home, pass telnet (not ssh, no need to encrypt twice) back form Mac to Linux, and pass X11 connections from Linux x clients to the Mac x server, all over the same ssh connection (or two parallel ones would be fine, just not one inside the other).

   Linux                                      Mac 
____________ ssh connection -> that way  ______________
|          |-----------------------------|            |
|    6010 --------------------------------> 6000      |
|      23 <-------------------------------- 2323      |
|          |-----------------------------|            |
|__________|                             |____________|

Then I can go home, sit at the Mac
telnet localhost 2323
and I've got a shell on the nice fast Linux box at school, and I can do my work, as long as it doesn't need a graphical application. But, I would like to set my DISPLAY on the Linux box such that it connects to port 6010 (hence :10) and it will be sent back to the X11 server on the Mac

As far as I know, the ForwardX11 only is for forwarding stuff from the ssh server to the ssh client, since that's the more typical arrangement. But I can't ssh into the school machine...

[michaelsanford]

Even though I, umm, wrote the FAQ, I can't figure out a solution for you at this time :P

[bossa nova]

gee wiz...sounds like you guys are light years ahead of where I am at. I am having trouble with the creation of keys. Specifically, when I login I am told that the connection is not known and "are you sure you want to do this?" Also what am I supposed to do with the key? Copy it onto a usb drive and then take it to the cpu I want a secure connection with?

michael...you have done a nice job and added some great tweaks.

what about just using port 80 which seems to be wide open everywhere?

[scruffy]

The keys live in ~/.ssh/known_hosts and known_hosts2. The first time you connect to a server from a particular client, it has never seen those host keys, so it asks you what to do. If you do connect that first time, then ssh will add the keys to one of the files.

Every time after that, when you connect to that server from that client, ssh will compare the keys the server sent this time, to the ones in the file from last time. If they match, it will just carry on; if they differ, then it may be a sign something fishy is up - you might be connecting to a bogus server.

[michaelsanford]

Originally Posted by bossa nova

michael...you have done a nice job and added some great tweaks.

what about just using port 80 which seems to be wide open everywhere?

Thanks

What exactly do you mean about port 80 though?

PS Scruffy has it totally right, but also of note is the fact that you will need to add a key for every different name you use to connect to the host. For example, I can connect to my other iMac, called homsar, buy either homsar.local, homsar, 192.168.0.22, or homsar.no-info.com, and all those names will prompt you to add a new key to your known_hosts since ssh doesn't know that they're all the same computer...

[bossa nova]

Originally Posted by michaelsanford

Thanks

What exactly do you mean about port 80 though?

You're welcome...with regard to port 80, I was thinking that it would be open to incomming traffic but then I realized that most web servers (in a perfect world), would probably be in a DMZ or outside of the firewall. So I guess I just answered my own question. But this gets me thinking. If you want to use port 22, you would have to ensure that the port was open. Unless you punch a hole through from the other side right?

[michaelsanford]

Actually in a perfect world we wouldn't need firewalls at all :P However, it's not considered good practice to put big servers in a DMZ and I'm not really sure why you'd need or want to.

As for using port 22, you need to make sure that the port is open for incoming traffic on the server's firewall.

The advantage to all of this is that port 22 is: (a) a privileged port, so you need to be root to run services on it (or any port below 1024) so at, in theory malicious, script-kiddies and hackers can't run arbitrary services on it to say, fake an ssh connection and get your username and password; (b) since the connection is encrypted it's secure; and lastly (c) that you can forward nearly any other insecure service through SSH at port 22 that you can close to the outside world.