"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-----------+ 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 |
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. |
Quote:
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 |
shall this work`´?
Quote:
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:
EDIT: I may have it partially: cat sshserver.sh Code: Quote:
Code: Quote:
|
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 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.
|
Quote:
Linux could program better then? We have to find solutions. Why not secured enough? |
Quote:
"- POSSIBLE BREAK-IN ATTEMPT!" into my auth.log during my reverse ssh ?? seems like dangerous |
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 |
Quote:
what is the difference with ftp, which is highly breakeable by pirates? :) I mean ssh > more secured than ftp and it is under controle |
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 |
Quote:
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. |