ssh port blocked. What options do I have?
Rahul
failed because the outgoing traffic via ssh-port 22 was blocked (I
suspect). Is there any hack to get around this? Of course, port 80 for http
was open. So were all standard email ports.
In the past when a specific app. port was blocked I've tunnelled
successfully via ssh. But what options does one have when ssh itself is
blocked?
Can ssh traffic piggyback on top of anything else?
--
Rahul
Rahul
news:Xns9C0375CDDAD1F66...@85.214.105.209:
> Can ssh traffic piggyback on top of anything else?
>
Maybe I was just googling up the wrong keywords. Right after I posted I
have some sparks of brilliance and find this bit about "ssh over http".
Maybe that saves me the next time.
http://dag.wieers.com/howto/ssh-http-tunneling/
--
Rahul
Chrisjoy
When you say you tunnelled when another service port was blocked I
assume you had a machine to tunnel via. If so, why don't you set this
machine to service ssh on yet another port?
If hotspot on the other hand recognize ssh by packet inspection and
blocks it, or even worse, they block everything but 80,8080,110 and
25, then you can camouflage your ssh though web's put and get
commands. I saw such a project some time ago, but don't remember the
name.
Grant Edwards
> I was trying to connect via ssh from WiFi in a coffeeshop
> earlier and I failed because the outgoing traffic via ssh-port
> 22 was blocked (I suspect).
I presume you mean traffic "to ssh-port 22" was blocked?
> Is there any hack to get around this? Of course, port 80 for
> http was open. So were all standard email ports.
>
> In the past when a specific app. port was blocked I've
> tunnelled successfully via ssh. But what options does one have
> when ssh itself is blocked?
You can try running sshd on port 80 (http) or port 443 (https),
or port 993 (imaps) or port 143 (imap).
Better yet, patronize a better class of coffee shop that
doesn't block access to ssh servers. You could also ask the
coffee shop to fix their router configuration (or at least let
them know why you're taking your patronage elsewhere).
> Can ssh traffic piggyback on top of anything else?
Not using vanilla sshd.
Another option is to sign up for an account with a VPN service
such as vpnout.com. They have openvpn servers listening on all
TCP and UDP ports. Once you're connected to the VPN server you
have secure, unadulterated access to the 'net via the VPN
connection. That also has the advantage of preventing anybody
in the coffeeshop from evesdropping on what might otherwise be
cleartext traffic.
--
Grant Edwards grante Yow! I think my career
at is ruined!
visi.com
Nathan Keel
I'm going to assume this is blocked on the network level, which you
don't have control over. If you control the target system you want to
connect to, maybe you could bind it to port 80 on the remote system?
Chris Davies
> Another option is to sign up for an account with a VPN service
> such as vpnout.com. They have openvpn servers listening on all
> TCP and UDP ports.
What an elegantly simple idea. Now if only I'd thought of that... :-)
Chris
Chrisjoy
I don't think this idea is any good at all. By following it you have
added yet another single point of failure, a point you do not control.
This said, his root seaching point is very good. Most hotspots don't
protect the surfers from eachother. One cannot call'em irresponsible
either, because the 802.11+ community, and WiFi in perticular have not
made security between clients mandatory. Even if a hotspot is open,
traffic between AP and Client should be protected with a unique key to
protect each client from sniffing. One may say that this is not a
perfect protection because you are still are vulnerable to people who
got control over the hardwires. Such an objection isn't meaningful
though, because it's an attack against how the whole internet works.
We may wish all services offer an end to end protection against
sniffing, but this will never happend. Still we should want to tighten
the greatest security holes.
Grant Edwards
One especially elegant detail is that openvpn uses the SSL/TSL
transport layer just like HTTPS does. That means there's no
way simple way for a firewall or proxy-server to tell the
difference between an HTTPS connection to a web server
somewhere, and an openvpn session on port 442.
You could probably tell the difference with some long term
traffic analysis, but simple packet inspection won't work.
--
Grant Edwards grante Yow! VICARIOUSLY experience
at some reason to LIVE!!
visi.com
pk
Another option is to use httptunnel, which doesn't require an actual http
server.
See http://www.nocrew.org/software/httptunnel.html and
http://en.wikipedia.org/wiki/HTTP_tunnel_(software)
for more information.
Rahul
news:K6qdnbg1gePMZZ_X...@posted.visi:
> One especially elegant detail is that openvpn uses the SSL/TSL
> transport layer just like HTTPS does. That means there's no
> way simple way for a firewall or proxy-server to tell the
> difference between an HTTPS connection to a web server
> somewhere, and an openvpn session on port 442.
>
> You could probably tell the difference with some long term
> traffic analysis, but simple packet inspection won't work.
>
Thanks for all the sugesstions guys!
--
Rahul
Unruh
>I was trying to connect via ssh from WiFi in a coffeeshop earlier and I
>failed because the outgoing traffic via ssh-port 22 was blocked (I
>suspect). Is there any hack to get around this? Of course, port 80 for http
>was open. So were all standard email ports.
On your home machine, assuming it is not a web server, you have ssh listen on port 80
as well as port 22.
Then you just do
ssh -p 80 name.of.home.machine
at the coffee shop