Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have seen this question: http://serverfault.com/questions/33283/how-to-setup-ssh-tunnel-to-forward-ssh but I'm having difficulties because of OS barriers. I have someone sitting on an XP laptop behind a router that they cannot configure. I have them running freeSSHd and I need to connect to it. I have my personal SSH server and can access it freely. The other person only has puTTY as an option for an SSH client, which makes this confusing (especially since she is not extremely tech savvy). I understand the concept of using an SSH tunnel to connect to HER server through MY server, but I don't seem to be able to make it happen. Right now I have her connecting via puTTY to MY server with the remote tunnel with (source: 1357) and (destination: localhost:23). Her freeSSHd server is running on port 23. However, when I try to connect via SSH to my server on port 1357, I get a connection refused error. What is wrong with this setup?

Final Answer:

Firstly, in sshd_config add GatewayPorts clientspecified. Then, in puTTY, add a REMOTE tunnel with a SOURCE PORT <rport> and DESTINATION localhost:<sport> (where <rport> is the port you want the public SSH server listening on and <sport> is the port that your local, firewalled SSH server is listening on). Make sure both boxes at the top of puTTY's Tunnels page are checked. This is equivalent (if I understand correctly) to ssh -N -g -R <rport>:localhost:<sport> user@public_server. Then, you should be able to SSH into the public server connecting to <rport> and it will forward you properly to the firewalled server. At least, it worked for me...

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

You'll need to make sure it's a reverse tunnel, so under SSH->Tunnels ensure the buttons at the bottom say "Remote" and "Auto (or IPv4)". I couldn't get this working however so I'd be interested to see what the problem was.

share|improve this answer
    
Also, make sure that GatewayPorts is permitted in your sshd config on the server. –  James Lawrie Aug 24 '10 at 19:29
    
So, GatewayPorts has been set to clientspecified and the boxes in puTTY to allow connections from remote hosts has been checked. While doing this, a though occurred: shouldn't I be able to just log into the SSH server, and while inside it SSH into itself on a different port? And if that port happened to be a reverse-tunnel heading towards the firewalled-person's server? I am trying it now... EDIT: failure. I can SSH into the same server (loopback) but any port besides 22 is still refusing the connection –  Jonathon Aug 24 '10 at 19:37
    
Also interesting to note: sudo netstat -p -tcp shows nothing listening on port 23, which is the port we are setting the reverse tunnel on... –  Jonathon Aug 24 '10 at 19:40
    
You're not setting the remote tunnel on 23 you're setting it on 1357 so the netstat command will show nothing on the server, but should show on the client. If you were using :23 you'd fail anyway because only root can open ports <1024. Check /var/log/secure when they try to connect, it should show any issues with the tunnel. Also might be worth checking /var/log/messages. –  James Lawrie Aug 24 '10 at 19:49
    
Also, to see if the tunnel is hitting the client, do an IPTables log on her machine: iptables -A INPUT -p TCP --dport 23 -j LOG Then do a tail on /var/log/messages when you try to connect via the tunnel: tail -f /var/log/messages –  James Lawrie Aug 24 '10 at 19:50
show 2 more comments

Firewall possibly? Also, you might have TCPWrappers enabled, so check what's in your /etc/hosts.deny file, if you are denying anything, or all, then you might have to permit it through /etc/hosts.allow. Also check for any software firewalls (I know I said firewalls first, but I was referring to hardware firewalls, such as a router, PIX, etc).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.