• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

remote ssh tunnels

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
I need to create a remote tunnel from a remote computer back to the local computer initiating the ssh session. So computer A ssh connects to computer B and I want to tunnel port 80 from computer B back to computer A.

It works when computer A logs in to ssh on computer B as root. Then any user on computer gets a port 80 tunnel back to computer A. But I would prefer that computer A logs in to ssh on computer B as user1 and then user1 can log in locally (or any user) and have port 80 tunneled to computer A but this does not seem to work as user1. Anybody know why or if there is not possible to do it that way?
 

Crusty

Lifer
Sep 30, 2001
12,687
1
0
Opening a listening socket on any port below 1024 requires root in Linux.
 

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
Originally posted by: Crusty
Opening a listening socket on any port below 1024 requires root in Linux.
so should I be able to tunnel port 8080 from remote computer B back to port 80 on computer A then?
 

Crusty

Lifer
Sep 30, 2001
12,687
1
0
I just reread your post and now I'm just confused.

What is Host A and what is Host B? Does host B have a service listening on port 80 that you want accessible on Host A through the SSH tunnel? If so you don't need root access on Host B.

But if you want Host B to open a socket on port 80 and forward over the SSH tunnel to port 80 on Host A then then yes you will need root access on Host B.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
0
0
Originally posted by: Brazen
Originally posted by: Crusty
Opening a listening socket on any port below 1024 requires root in Linux.
so should I be able to tunnel port 8080 from remote computer B back to port 80 on computer A then?
Yes.

Something like user@ComputerB $ ssh -L 8080:computerA:80 computerA should work (this is from memory, so might be a tiny bit off) to allow a user on ComputerB to open http://localhost:8080 and get to ComputerA:80 through the ssh tunnel.

If you did something like: user@computerA $ ssh -R 8080:ComputerA:80 computerB from ComputerA this would also work. I don't think you need root for this, but I could definitely be wrong.

All untested, not-RTFM'd, and I haven't messed with port forwarding in ages.
 

Crusty

Lifer
Sep 30, 2001
12,687
1
0
Well the first example would be kinda pointless because you are opening a shell on computer A but also forwarding over your tunnel to that computer. Granted the socket is still open on the local computer and you'll be able to use it outside of that current ssh session.. but I think the flags -f -N will force no shell and drop the connection into the background so you can use the tunnel transparently.

2nd example will work just fine as well. Just remember, you need root access if you do something like -L 80:computerA:80
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
0
0
Originally posted by: Crusty
Well the first example would be kinda pointless because you are opening a shell on computer A but also forwarding over your tunnel to that computer. Granted the socket is still open on the local computer and you'll be able to use it outside of that current ssh session..
Nothing pointless about having the shell open.

but I think the flags -f -N will force no shell and drop the connection into the background so you can use the tunnel transparently.
There's all sorts of fancy stuff you can do, I was just going minimal to keep the examples simple. ;)
 

Crusty

Lifer
Sep 30, 2001
12,687
1
0
Originally posted by: n0cmonkey
Originally posted by: Crusty
Well the first example would be kinda pointless because you are opening a shell on computer A but also forwarding over your tunnel to that computer. Granted the socket is still open on the local computer and you'll be able to use it outside of that current ssh session..
Nothing pointless about having the shell open.

but I think the flags -f -N will force no shell and drop the connection into the background so you can use the tunnel transparently.
There's all sorts of fancy stuff you can do, I was just going minimal to keep the examples simple. ;)
I was just saying that if you are going to be opening the shell you might as well just access the resource locally ;). At least I would :p

ssh tunnels are a great thing, I use them a LOT between servers with the help of autossh :)
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
0
0
Originally posted by: Crusty
I was just saying that if you are going to be opening the shell you might as well just access the resource locally ;). At least I would :p

ssh tunnels are a great thing, I use them a LOT between servers with the help of autossh :)
IPSEC FTW. ;)
 

Crusty

Lifer
Sep 30, 2001
12,687
1
0
Originally posted by: n0cmonkey
Originally posted by: Crusty
I was just saying that if you are going to be opening the shell you might as well just access the resource locally ;). At least I would :p

ssh tunnels are a great thing, I use them a LOT between servers with the help of autossh :)
IPSEC FTW. ;)
Some of the virtual servers we run don't have the right kernels for a software implementation and we're not big enough to collocate everything yet so a hardware solution is out of the picture. Although I do have an IPSEC tunnel into one of the data centers that we use to dump backups over, but it doesn't encrypt any intraserver traffic locally in the data center.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
0
0
Originally posted by: Crusty
Some of the virtual servers we run don't have the right kernels for a software implementation and we're not big enough to collocate everything yet so a hardware solution is out of the picture. Although I do have an IPSEC tunnel into one of the data centers that we use to dump backups over, but it doesn't encrypt any intraserver traffic locally in the data center.
I had an IPSEC tunnel going between my servers at home before I tore everything down (moving, haven't set it back up yet). Unfortunately I think the VIA processor (OLD, no padlock) is a bit too slow to handle it well. Between IPSEC and puppetd the system kept dying. :p

Upgrades are being planned though (got the official OK from the "boss"). :D
 

ASK THE COMMUNITY

TRENDING THREADS