LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   General (https://www.linuxquestions.org/questions/general-10/)
-   -   "SSH tunneling" is a confusing Joke solving anything because you have to be admin (https://www.linuxquestions.org/questions/general-10/ssh-tunneling-is-a-confusing-joke-solving-anything-because-you-have-to-be-admin-728414/)

frenchn00b 05-25-2009 03:39 PM

"SSH tunneling" is a confusing Joke solving anything because you have to be admin
 
http://www.linuxhorizon.ro/ssh-tunnel.html

Code:

  +----------+<--port 22-->+----------+<--port 80-->o-----------+
  |SSH Client|-------------|ssh_server|-------------|  host    |
  +----------+            +----------+            o-----------+
  localhost:8888              computer      www.linuxhorizon.ro:80


lol

if
SSH CLIENT = port 22 => outgoing is open

So what does linux to do secured connection? Is there any alternatives that Remote SERVER == port22 => accepted by CLIENT then loopbakc the SSH to gain access to the SERVER (CLIENT IS THE MASTER and typing)

that would be secured and NOT using ANY port 80

acid_kewpie 05-25-2009 04:43 PM

What is the question?? your English is normally much better than that... I'm afraid don't follow.

The diagram you've posted is a perfect example of ssh tunneling, getting a connection between the web client and browser partially via an encrypted ssh connection. That's exactly what it's for.

frenchn00b 05-25-2009 05:37 PM

Quote:

Originally Posted by acid_kewpie (Post 3552423)
What is the question?? your English is normally much better than that... I'm afraid don't follow.

The diagram you've posted is a perfect example of ssh tunneling, getting a connection between the web client and browser partially via an encrypted ssh connection. That's exactly what it's for.

oups sorry
I mean tunneling is really tricky thing

so I try to make a jpg shot to explain what I may target with high security:
http://img33.imageshack.us/my.php?im...chloopback.jpg

frenchn00b 05-25-2009 07:21 PM

shall this work`´?
Quote:

<code>
$ ssh -nT -R 5000:friendipaddress:5000 myipaddress
</code>
if friend has sshd having 5000 as port.


What this does is initiate a connection to remote.mydomain.com and forwards TCP port 1100 on remote.mydomain.com to TCP port 1100 on local.mydomain.com. The "-n" option tells ssh to associate standard input with /dev/null, "-N" tells ssh to just set up the tunnel and not to prepare a command stream, and "-T" tells ssh not to allocate a pseudo-tty on the remote system. These options are useful because all that is desired is the tunnel and no actual commands will be sent through the tunnel, unlike a normal SSH login session. The "-R" option tells ssh to set up the tunnel as a reverse tunnel.

Now, if anything connects to port 1100 on the remote system, it will be transparently forwarded to port 1100 on the local system.


It seems that I have it:
Quote:

Reverse SSH Tunneling

Have you ever wanted to ssh to your Linux box that sits behind NAT? Now you can with reverse SSH tunneling. This document will show you step by step how to set up reverse SSH tunneling. The reverse SSH tunneling should work fine with Unix like systems.

Let's assume that Destination's IP is 192.168.20.55 (Linux box that you want to access).

You want to access from Linux client with IP 138.47.99.99.

Destination (192.168.20.55) <- |NAT| <- Source (138.47.99.99)

1. SSH from the destination to the source (with public ip) using command below:

ssh -R 19999:localhost:22 sourceuser@138.47.99.99

* port 19999 can be any unused port.

2. Now you can SSH from source to destination through SSH tuneling:

ssh localhost -p 19999

3. 3rd party servers can also access 192.168.20.55 through Destination (138.47.99.99).

Destination (192.168.20.55) <- |NAT| <- Source (138.47.99.99) <- Bob's server

3.1 From Bob's server:

ssh sourceuser@138.47.99.99

3.2 After the sucessful login to Source:

ssh localhost -p 19999

* the connection between destination and source must be alive at all time.

Tip: you may run a command (e.g. watch, top) on Destination to keep the connection active.

EDIT:

I may have it partially:

cat sshserver.sh
Code:

Quote:

#!/bin/sh
# user@ip
# $2 shall be -p
# $3 is the port on the target
ssh -R 5637:localhost:`cat /etc/ssh/sshd_config | grep Port | cut -d' ' -f 2` $1 -p $3
cat sshclient.sh
Code:

Quote:

#!/bin/sh
# $1 is the user
# $2 shall be -p
# $3 is the port on the target
# ssh -R 5637:localhost:`cat /etc/ssh/sshd_config | grep Port | cut -d' ' -f 2` $1 -p $3
ssh $1@localhost -p 5637

ilikejam 05-25-2009 08:43 PM

Yup. Poor man's VPN.

A word of warning if you're going to do this for real:
1) Network and security teams don't like it, since it relies on the security of a remote machine.
2) Some routers/firewalls drop connections after a while if there's no traffic, so you might find yourself locked out. I used to run a 'spinner' script on the remote side to keep a small amount of data flowing all the time.

Dave

acid_kewpie 05-26-2009 02:06 AM

You appear to be mixing up normal ssh tunnelling (-L) and reverse ssh tunnelling (-R). As they do the opposite to each other you want to be clear which direction you want to tunnel. if you want to make browsing to localhost:8888 show remotehost:80 then that's normal tunnelling. if you want to connect to a remote machine and let a remote user access your webserver on your local machine by them going to sshserver:8888 then that's reverse tunnelling, and much less common.

frenchn00b 05-26-2009 05:01 PM

Quote:

Originally Posted by ilikejam (Post 3552552)
Yup. Poor man's VPN.

A word of warning if you're going to do this for real:
1) Network and security teams don't like it, since it relies on the security of a remote machine.


Dave

I did, I do, I like, I can pass through the firewalling, finally !!!
Linux could program better then? We have to find solutions. Why not secured enough?

frenchn00b 05-26-2009 05:43 PM

Quote:

Originally Posted by ilikejam (Post 3552552)
Yup. Poor man's VPN.

A word of warning if you're going to do this for real:
1) Network and security teams don't like it, since it relies on the security of a remote machine.
2) Some routers/firewalls drop connections after a while if there's no traffic, so you might find yourself locked out. I used to run a 'spinner' script on the remote side to keep a small amount of data flowing all the time.

Dave

you meant:
"- POSSIBLE BREAK-IN ATTEMPT!" into my auth.log
during my reverse ssh ??

seems like dangerous

ilikejam 05-28-2009 07:06 AM

As far as I remember, the POSSIBLE BREAKIN message appears when the connecting hosts reverse lookup comes back with an weird hostname/IP.

"Linux could program better then? We have to find solutions. Why not secured enough?"
Not especially - the reason network teams don't like it is because you're punching a hole in their firewall and they can't make any promises about the security of a machine that's not on their network.

Dave

frenchn00b 05-28-2009 10:14 AM

Quote:

Originally Posted by ilikejam (Post 3555316)
As far as I remember, the POSSIBLE BREAKIN message appears when the connecting hosts reverse lookup comes back with an weird hostname/IP.

"Linux could program better then? We have to find solutions. Why not secured enough?"
Not especially - the reason network teams don't like it is because you're punching a hole in their firewall and they can't make any promises about the security of a machine that's not on their network.

Dave

I mean I do not know what is wrong. You are just having an host into you computer, so ? and you do ssh external.

what is the difference with ftp, which is highly breakeable by pirates? :)
I mean ssh > more secured than ftp and it is under controle

ilikejam 05-28-2009 10:38 AM

If you tunnel out of your firewalled network from host A to host B outside, and use 'ssh -R' to connect a port on B to port 22 on A, then anyone who has access to B also has access to the SSH daemon on A. While you and me would see that as an OK security risk (you'd still need a password/key to do anything with the connection), you can bet that they guy that runs the firewalls will probably not.

I'm just speaking from experience of Network team Vs Unix team, really. I did exactly what you posted above to give me access to my work's network while proper VPN accounts were being set up, knowing that the external machine is well secured. Management were quite impressed that I'd found a way to get reasonably secure access, but I've been quite rightly asked not to do this (I've left the infrastructure in place in case I need it again, though ;)).

On the other hand, if the same people that run the Unix side also run the firewalls, then I'd say there'd probably be no problem.

Dave

ProtoformX 05-28-2009 12:35 PM

Quote:

Originally Posted by ilikejam (Post 3555519)
If you tunnel out of your firewalled network from host A to host B outside, and use 'ssh -R' to connect a port on B to port 22 on A, then anyone who has access to B also has access to the SSH daemon on A. While you and me would see that as an OK security risk (you'd still need a password/key to do anything with the connection), you can bet that they guy that runs the firewalls will probably not.

I'm just speaking from experience of Network team Vs Unix team, really. I did exactly what you posted above to give me access to my work's network while proper VPN accounts were being set up, knowing that the external machine is well secured. Management were quite impressed that I'd found a way to get reasonably secure access, but I've been quite rightly asked not to do this (I've left the infrastructure in place in case I need it again, though ;)).

On the other hand, if the same people that run the Unix side also run the firewalls, then I'd say there'd probably be no problem.

Dave

The idea behind the "leave the infrastructure in place" is because if you don't it gives crackers something, it doesn't matter if they have the password or not, the idea is never to expose anything to the outside world that shouldn't be exposed. If you have ever setup a linux/unix box you know to never allow apache to start as root, why? it's secure isen't it?

Same reason, no code is 100% secure, that being said there is always the chance with an exploit or even a socal engineering attempt they could gain access to the server. if there is no outside box that has SSH it makes it harder. The idea is to give the least possible resource to a cracker.


All times are GMT -5. The time now is 06:18 AM.