SSH Tunnels?

[ZiaTioN]

I have been trying to create an ssh tunnel from port 23 on my server to port 22 on a remote server. I am doing this because my wifes stupid company firewalls all outgoing ports except port 23 and 80. Therefore I want to configure a tunnel from my servers port 23 to our webhost servers port 22.

Now I have been able to successfully accomplish this however the shell window needs to remain open for the tunnel to stay open. I of course have tried spawning the command to the background with "&" but this does not jive simply because when the tunnel is created it asks for the password for the remote server. Now I also have tried the -f flag for ssh but a command to run on the remote server needs to be given in order to allow the tunnel to fork into the background. I have tried issueing "cat -" to keep the tunnel open indefinately and this works sometimes but somewtimes does not.

Anyway here is the syntax I am using:

ssh -L 23:localhost:22 user@host.com

ssh -f -L 23:localhost:22 user@host.com cat -

My question is, is there a better way to start this tunnel and have it fork and stay open indefinately?

[Void Main]

I don't quite understand what you are after here. I have done a lot of port forwarding with ssh and VPN tunnels with FreeS/WAN and OpenVPN. What kind of traffic do you need to get between the two hosts, just ssh or more? You could also just have ssh listen on a port other than 22 (on a port that the company *does* allow, like 443 (if you are not using it)). Then you can just:

$ ssh -p 443 yourserver

OpenVPN will create a tunnel between the two boxes and give you access to all ports on your entire network. It is really easy to set up and you could have it listen on port 23 rather than the default port but again, I am not quite sure what you are after. It seems odd they would allow 23 and 80 (two unencrypted ports) but nothing else.

[ZiaTioN]

It seems odd they would allow 23 and 80 (two unencrypted ports) but nothing else

That is exactly what I said which is why they are stupid. The server I am forwarding to is not under my control. However I do have a friend that has root access to it and he said he would configure ssh to listen on a second port for me (the way I have done my own server) but will not do it remotely. The server is located about 45 minutes away from us both and he said he would do that next time he went up there, which could be a while. So for an interim solution I am trying to use this tunnel from a box I do have control over to that server.

As I said I can create the tunnel but I want to fork it into the background and run it as a psuedo deamon. The two ways I tried in my first post are not adequate enough for what I want.

[ZiaTioN]

Ok well I found the proper syntax. Here it is if anyone is interested!

ssh -l user -g -C -N -f -L 23:localhost:22 host.com

Flags:
-l = user to log in as
-g = Allow remote hosts to connect to forwarded ports
-C = Enable compression
-N = Do not execute a shell or command
-f = Fork into background after authentication
-L = Forward local port to remote address

The two major ones I was missing before was -N and -g. Without -g only local connections from my server would have been accepted and withour -N I would have to try and come up with some command to run on the remote machine to stay open.

This is where my second challenge began. I needed to write a script that I could have executed if and when the server was rebooted via rc.local as to re-establish the tunnel. Of course I tried perl first and this was just one of those very very rare instances where perl just was not going to get it done. So I had to dust off my Expect skills and give it a go. Expect is perfect for this kind of system interaction and in the end it was exactly what the doctor ordered. Here is the expect script I wrote to accomplish automating the tunnel setup.

Code: Select all

#!/usr/bin/expect
spawn ssh -l user -g -C -N -f -L 23:localhost:22 host.com
set password userpass
expect {
   password: {
      send "$password\r"
      expect {
         bind: {
            close; wait
            send_user "SSH Tunnel Created!\n"
         }
      }
   }
   timeout {
      send_user "Error: SSH tunnel creation failed.\n"
   }
}


[Void Main]

You know you also could have made the connection without requiring a password by using a key. Then you do not need any script, just run the command. I do this all the time. If you have not already created your key you do it with "ssh-keygen -t dsa" on your client. Add the contents of your "id_dsa.pub" on your client to your servers ~/.ssh/authorized_keys. It should no longer ask you for your password for any ssh operation between the two users on the two machines.

[ZiaTioN]

I thought about that but considered possible security issues with doing this. I have read conflicting opinions on this. Some recommend against it and some champion it. Will probably be something I end up doing but for now this will appease my paranoid nature.

[Void Main]

It's more secure than the way you are doing it in my opinion because there is no password floating around.

[ZiaTioN]

Well not neccessarily. If I do it this way anyone who decides to ssh to my servers port 23 will automatically be forwarded to the remote server like they are suppose to be and then automatically be logged in. Since I allow outside addresses to use the forwarded port this could be a security issue.

Am I wrong in assuming this? It makes since that if a tunnel setup will not ask for a password and use the key then anyone who uses the tunnel will also not be asked for a password.

[Tux]

No, anyone with the key can log in. The shared key is your authentication.

[Void Main]

The password that you are scripting in is the password to log in to host to set up the tunnel correct? You can use a key rather than a password for this, and this is only for setting up the tunnel. Once the tunnel is set up there is no difference whether you used a password or a key to access the server to set up the tunnel in the first place. As long as you keep your private key private (stays in your ~/.ssh directory on the client) then things are more secure than using passwords actually. In fact if anyone other than you (and root) have access to your private key ssh will not use it because it can't be trusted and it will prompt you for a password.

Now, you need to make sure you take caution to restrict access to the port that is forwarded and the server on the other end of it just as you would had you had direct access to it (restrict access to specific hosts/networks and have good passwords). You could also use a key rather than password for logins over the forwarded port if you wanted. I used keys on everything. Very rarely do I type in a password to get to other servers. Like Tux said, if your private key doesn't match the public key that you put in your autorized_keys file on the remote end then you ain't getting in, which also means no one else is getting in without a password because they better not have your private key. The important thing is to keep your private key private as always. Think of it as your private key IS your password.

[ZiaTioN]

I had a chance to check this out and it is much simpler then using the script. Although it was a fun exercixe writing the script it is simply better to use the key. I was only worried that once the session/tunnel was setup between the two machines using a key that it was an open pipe for outside connections to walk through. I was just not thinking about the similarities of establishing a tunnel with a pass as aposed to a key. Establishing a tunnel with a password does not leave a wide open pipe for outside connections to walk through therefore why would a tunnel authed by a key do any different.

You know though it would have been nice of you to suggest this BEFORE I wrote the expect script!

[Void Main]

You learn more by doing things the hard way first. I'm just helping out. :)