I am currently trying to work out how to SSH to servers behind firewalls that deny all incoming connections. The servers can SSH out, so I am wondering if there is a way to get the server behind the firewall to create an SSH tunnel to my workstation, then allow my workstation to send commands back to the server through it?
I have looked into tunneling / reverse tunneling, but these appear to be port forwarding solutions, which will not work as the firewall denies all connections on all ports.
Ideally, I would like to do this in Ruby (using the Net::SSH gem), such that instead of opening a new connection like:
Net::SSH.start('host', 'user', :password => "password")
I could somehow bind to an existing tunnel.
Thanks!
This is fairly simple if you have control over the server. I'll give the command-line version, and you can work that into any framework you like:
server$ ssh -R 9091:localhost:22 client.example.egg
client$ ssh -p 9091 localhost
The server establishes a connection to the client first which starts listening on the "R"emote end (i.e. the client) on port 9091 (something I just made up), and forwards those connections to localhost:22, i.e. to the ssh server on itself.
The client then just needs to connect to its own local port 9091, which is transparently forwarded to the server's ssh server.
This will usually wreak havoc to your public key checking (and adherent security!), because the client's ssh client doesn't know that localhost:9091 is the same as server:22. If your client is Putty, then you have an option to provide the "real" server name somewhere so that the credentials can be looked up properly.
Unless you can create (and maintain) a tunnel out from the host you're trying to connect to first (which would allow you then to connect through that tunnel), no you can't. That's the point of a firewall: prevent unauthorised access to a network.
However the firewall shouldn't block a tunnel, although it depends exactly how the tunnel's managed. A port-forwarding tunnel set up using ssh's tunneling features would subvert the firewall. However it may also get you in trouble with the administrator of the remote network.
So ultimately, you'd need to speak to the network administrator to get the firewall rules relaxed in order to do it without needing to tunnel, or at least get authorisation to have a tunnel.
Related
I'm wondering actually about the difference between usage of stunnel and ssh port-forwarding (-L and -R flags functionality). I know that both things are difference solutions - SSH tolerates its own keys, stunnel relies on SSL and certificates as a wrapper around TCP/UDP traffic, and so on.
But in the end - let's say you want to connect to some internal service that is inside local (a private network) and still you can do it in two ways:
deploy hardened instance (exposed to public ) that will work for you as a jump host (use SSH port forwarding)
deploy hardened instance (exposed to public) that will host stunnel server and wait for a connection from any stunnel client
I will be grateful for your thoughts about that!
stunnel and ssh are for very different situations.
ssh is a standard tool to connect to a machine and you can use local/remote forwards on top of your tunnels.
stunnel is used in case of firewalls with deep packet inspection, blocking ssh traffic. It can also be used to hide the real used protocol, can be necessary in some countries.
If you are behind a strong firewall, you are simply not able to use ssh, but stunnel still works, because it looks like ordinary https traffic.
But on top of using stunnel, you are normally use other protocols, like ssh.
The stunnel is only used to tunnel the firewall and ssh is used for the real connections then.
The scenario is as follows: I have a VPS (Droplet) in Digital Ocean (DO), I connect via putty-ssh, however I must have another user enabled with root privileges and with password access (without ssh), this is because When there are connection problems through putty-ssh, I must enter through my DO account, and access the droplet console using that user with a password to fix the problem. This usually happens every time I restart the server and I can not connect with any user from putty, the connection is rejected. The solution is simple, restart ufw and everything solved.
However I open a door for hackers who can easily break this user password with all privileges. The idea is to allow this user to connect only from my personal IP, but the Ubuntu firewall only allows IP / port / application rules, no user can be referenced. How could I solve this problem?
After much research and testing and more tests, specifically with the commands telnet and login, I discovered something I did not know; when the SSH service is active, only ssh connection with a private key is allowed, no other connection is allowed, even with ssh+password. This feature, either integrated into Ubuntu, or is implemented by Digital Ocean, I guess the first.
Considering this, there is no problem that raised in this question; no one can connect to the server unless you have the private key, and if you also only allow the ssh connection from a specific IP, the security is very good. By configuring the firewall in this simple way, it will be sufficient:
ufw status verbose
To Action From
-- ------ ----
8000 ALLOW IN Anywhere
6666/tcp ALLOW IN 15.15.15.15
8000(v6) ALLOW IN Anywhere (v6)
Port 8000 for incoming requests from HTTP and HTTPS clients, which will be managed by django, and any port other than the default 22 for ssh, specifying the private IP of my computer, I can only connect from my computer with the corresponding private key. We will also have to modify the ssh configuration file which is the file /etc/ssh/sshd_config replacing port 22, PasswordAuthentication no and restarting the service with service ssh restart.
When I am working at the University, the program I use for managing papers (Papers2, from mekentosj), connects to the EZproxy, so that it can download papers.
When I am at home, I can't do this. My question is can I somehow setup an SSH tunnel to the University so that the program Papers can log into the EZproxy from home?.
P.S. As a follow-up to comments, I have the right to set up an SSH tunnel at our University, on my Linux machine.
Since you stated that you have SSH access to your university, you can use Dynamic Port Forwarding:
ssh -D LOCAL_PORT USER#UNIVERSITY_MACHINE_IP allows you to forward each connection through the LOCAL_PORT you specified on your machine.
Go your OS's connection settings
Check Manual Proxy Settings
Enter 127.0.0.1 in the SOCKS field.
Enter LOCAL_PORT you choose to Port field.
Now, every connection protocol (HTTP, FTP, etc.) will be forwarded through the university machine you connected.
Note:
Be sure to select an unused port on your computer bigger than 1024 as LOCAL_PORT
You can only do this while your SSH connection is still alive.
You can also configure browser-only forwarding from the settings of your browser of choice.
Still not enough information to create a pre-fabricated solution for you. Anyway, a few resources:
How to set Papers library proxy: I do not know if you can create your own proxy, e.g. on localhost:2048, tunnelling through to the university.
How many (and which) proxy ports does EZproxy use? This should help you determine the SSH tunnel settings you need for your connection
Your university's EZproxy administrator: Ask her if she can tell you how to set up remote access. Maybe there is an official way to set this up, possibly an already existing, externally accessible proxy URL or SSH hopping station, maybe a VPN or whatever.
Although I use some alias to do ssh tunnel or reverse tunnel, I never understand how it works. Does somebody know how to explain it in very simple way?
I think the 3 primary uses are:
First of all, I can use my home computer to ssh to foo.mycompany.com, without using any password
(foo is a server at work)
How to make foo.mycompany.com:8080 go to my home computer's localhost:3000 ?
If at home, I cannot access http://bar.mycompany.com, but foo can access bar, how to make the home computer able to access http://bar.mycompany.com?
If at home, I cannot access MySQL db at db.mycompany.com, but foo can, how to make it possible to access db.mycompany.com also using ssh tunnel.
Can it be explain in very simple terms? Are there actually some other popular use besides these 3? thanks.
1) Assuming you connect from home to foo, you need a reverse tunnel (-R)
ssh -R 8080:localhost:3000 foo.mycompany.com
This will enable processes running at foo to connect to localhost:8080 and actually speak to your home computer at port 3000. If you want other computers at your work to be able to connect to foo:8080 and access your home computer at port 3000, then you need
ssh -R 0.0.0.0:8080:localhost:3000 foo.mycompany.com
but for this to work you also need this option to foo's sshd_config
GatewayPorts yes
2) The best way to create an http proxy with ssh is with socks. First connect with
ssh -D 8888 foo.company.com
then go to your browser connection settings and enable proxy connection, choose socks4/5 and host: localhost, port 8888. Then just type http://bar.mycompany.com in your browser's address bar.
3) Now you need a local port forward (-L).
ssh -L 3333:db.mycompany.com:3306 foo.mycompany.com
This means that you will be able to connect at localhost:3333 from your home computer and everything will be forwarded to db.mycompany.com:3306 as if the connection was made by foo.mycompany.com. Host db will see foo as the client connecting, so you need to login with the same username and password you use when working from foo.
Adding -g flag will enable other computers from your home network to connect to your computer port 3333 and actually access db:3306.
SSH tunnelling is very simple. It opens a listening socket at one end. Whenever anyone connects to that listening socket, it opens a corresponding connection from the other end to the configured location, then forwards all information both ways between the two, over the SSH link.
Quite an old question, but see if this page helps explain it for you, it's got pretty pictures and all. :)
https://www.ssh.com/ssh/tunneling/
Basically, a SSH Tunnel is a tunnel that can be used to pass (tunnel) data from one place to another, encrypted.
It is also commonly used to route traffic (via a tunnel, think wormhole) to somewhere else, which allows for things such as tunnelling through a firewall or redirecting traffic (encrypted port forwarding).
Let's say you have a firewall between you and the server. The server can access another server (server2) on it's internal network.
[client]--------||------[server]----[sever2]
Let's say you want to access a web server on server2, and for obvious reasons you can't do this directly. Let's say that port 22 (ssh) is open on the firewall. So what we would do is create an SSH tunnel (on server) from server to server2. This will mean that any (outbound?) traffic on port 22 will be sent, via this tunnel, from server:22 -> server2:80.
[client]--------||------[server:22]======[sever2:80]
So (as I understand it), if we connect to server:22, it should redirect traffic on port 22 to the web server on server2:80 using this new SSH tunnel. (as far as I understand, the data is only encrypted in the tunnel, so the end will be decrypted data, if you're wondering if server:80 has to be SSL).
I suppose in one way that using SSH, is in itself, an SSH Tunnel for your old telnet communication. It's just that in most times you hear about SSH Tunnelling, people are referring to the (secure) port forwarding feature it offers, without having to have access to the firewall admin, which is a nifty little feature that a lot of hackers like to use to get around security.
On the more legitimate reasons; it's great way to relay certain traffic to an internal server that works on a different port, should you be limited by a firewall and such, or you want to secure the traffic between two machines (like the SSH program does).
Hope this helps.
EDIT
Found this over at the UNIX SO https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work, lots of answers with very clear (and pictorial) explanations of what you need!
First of all I will explain SSH:
SSH is remote login shell that helps you to connect remote machines using encrypted connection. So once you made ssh connection to any remote host the connection between hosts are secure and encrypted.
SSH tunneling is routing your traffic through SSH secure connection.
In simple words SSH tunneling is nothing but one connection is encapsulated by another connection. By taking this as a advantage we make tunnels by using SSH client.
Following command helps you to create simple socks proxy
ssh -D 8080 user#sshserverip
Read the man page, specifically the -L, -R and -D options. I don't think someone rewriting this, and possibly introducing mistakes, is useful. If you don't understand it though you could ask more specific questions.
-D gives a SOCKS proxy, which is another useful application of ssh tunnelling.
At my workplace, the traffic blocker/firewall has been getting progressively worse. I can't connect to my home machine on port 22, and lack of ssh access makes me sad. I was previously able to use SSH by moving it to port 5050, but I think some recent filters now treat this traffic as IM and redirect it through another proxy, maybe. That's my best guess; in any case, my ssh connections now terminate before I get to log in.
These days I've been using Ajaxterm over HTTPS, as port 443 is still unmolested, but this is far from ideal. (Sucky terminal emulation, lack of port forwarding, my browser leaks memory at an amazing rate...) I tried setting up mod_proxy_connect on top of mod_ssl, with the idea that I could send a CONNECT localhost:22 HTTP/1.1 request through HTTPS, and then I'd be all set. Sadly, this seems to not work; the HTTPS connection works, up until I finish sending my request; then SSL craps out. It appears as though mod_proxy_connect takes over the whole connection instead of continuing to pipe through mod_ssl, confusing the heck out of the HTTPS client.
Is there a way to get this to work? I don't want to do this over plain HTTP, for several reasons:
Leaving a big fat open proxy like that just stinks
A big fat open proxy is not good over HTTPS either, but with authentication required it feels fine to me
HTTP goes through a proxy -- I'm not too concerned about my traffic being sniffed, as it's ssh that'll be going "plaintext" through the tunnel -- but it's a lot more likely to be mangled than HTTPS, which fundamentally cannot be proxied
Requirements:
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
I have or can write a simple port forwarder client that runs under Windows (or Cygwin)
Edit
DAG: Tunnelling SSH over HTTP(S) has been pointed out to me, but it doesn't help: at the end of the article, they mention Bug 29744 - CONNECT does not work over existing SSL connection preventing tunnelling over HTTPS, exactly the problem I was running into. At this point, I am probably looking at some CGI script, but I don't want to list that as a requirement if there's better solutions available.
Find out why the company has such a restrictive policy. It might be for a good reason.
If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.
To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.
If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECT to port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but then you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.
You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.
Try a rule like this:
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 443 -j REDIRECT --to-port 22
Where 111.111.111.111 is your office computer's ip address.
That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.
Documentation for iptables is at http://www.netfilter.org.
Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)
Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.
I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.
Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.
How about using 2 IP adresses on your machine?
Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?
Could you set up a middle man?
Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.
It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.
I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?
Proxy tunnel may be your answer
http://proxytunnel.sourceforge.net/
lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37
I would add this to my local ssh config
Host host.domain.tld
ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p
ProtocolKeepAlives 30
See:
SSH Through or Over Proxy
http://daniel.haxx.se/docs/sshproxy.html
http://www.agroman.net/corkscrew/
Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.
See http://chm.duquesne.free.fr/blog/?p=281 for details.
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
Is it possible to bind your HTTPS server to a different port? Depending on what it's used for, you may even be able to get around the problem of not being able to directly access it from work by just SSHing home and then using lynx from there.
So, then, give proxifier a try (- it supports HTTP Proxy Server)!
http://www.proxifier.com/documentation/intro.htm
I managed to bypass my company's firewall using the following design via AjaxTerm, it works for me.
PC on company network --> company's proxy via https --> INTERNET --> My home Apache reverse proxy server on SSL + .htpasswd protection --> AjaxTerm Server(From here on ward, I can SSH to any other servers ).
Still not the perfect world... would be good if I can can tunneling to my home network via HTTPS.