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.
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.
I know that I can run a socks5 proxy by ssh -D some-port-number remote-server-url.
I know that I can configure my applications (for example firefox) to use socks5 proxy (often by specifying something like socks5://localhost:that-port-number-metioned-above).
I hear people online referring to this technique as "socks5 proxy" or "ssh tunneling"; sometimes I even see people talking about "reverse ssh tunnling".
But as far as I know socks5 and ssh are totally different protocols, the only similarity between them is that they both have server-client architecture. Reading wiki definitions and googling on these concepts didn't clarify my confusion..
So how are these concepts -- SOCKS5 proxying, ssh tunneling, reverse ssh tunneling related with each other?
What you describe is a SOCKS proxy. It is standalone protocol used by various tools. What openssh does it to tunnel this protocol encrypted from one point to the other. But more precisely, it is called TCP port forwarding (it forwards one port from client through the secure tunnel to the server).
There are other possibilities to use TCP port forwarding in openssh using -L and -R switches that are correctly named Local ("brings" remote service to local host) and Remote (makes local service accessible from remote host).
As you can see, there are similarities, but they are implemented in different way. All of them are TCP port forwarding (through secure tunnel). The Dynamic (-D) special, because the server have to understand the SOCKS protocol.
I can't access to AWS EC2 instance from one day.
(AMI: ubuntu/images/ebs/ubuntu-precise-12.04-amd64-server-20121001 (ami-22ad1223))
$ ssh -v -i mykey.pem ubuntu#XXX.XXX.XXX.XXX
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: connect to address xxx.xxx.xxx.xxx port 22: Operation timed out
ssh: connect to host xxx.xxx.xxx.xxx port 22: Operation timed out
This is my "Security Groups" setting in EC2.
I did not change the setting from the time had a good connection.
Ports Protocol Source
22 tcp 0.0.0.0/0
80 tcp 0.0.0.0/0
3000 tcp 0.0.0.0/0
3006 tcp 0.0.0.0/0
I've tried many times to restart the server.
Web server is going well. However SSH connection is not.
What could be problem and how to make it work?
My usual checklist:
On AWS console: is the Instance up and healthy?
Is it in a public Subnet?
Does it have a public ip?
Does the VPC have an associated Internet Gateway?
Does it have the Routing Table to the Internet Gateway? (Attached to the subnet?)
Are the Network ACL rules default?
Does the Security group allow ping? If yes, does the ping work?
Does the Security group allow SSH inbound?
If there is still no clue, then fire up a new instance (from a base AMI) in the same VPC. Connect to it via SSH. If it was successful, try to ssh from that instance.
I too faced the same issue. Actually, by mistake, I deleted the default Internet Gateway.
Go to VPC and click "Internet Gateways" from the left menu.
Click "Create internet gateway" button and provide Name tag (any name - optional) and click create.
By default, it is detached. So click the Actions drop-down and select "Attach to VPC" and attach it with default VPC
Now go to "Route Table" and select default route table and edit the route by clicking "Edit routes" button under Routes tab
Then in the Destination text box provide "0.0.0.0/0" and in target select the newly created Internet gateway (starts with igw-alphanumeric) and save the route.
Now you should be able to SSH EC2 instance.
For newbies to AWS, like me, remember the hostname can change if you reboot or stop/start your instances. So remember to use the right hostname - visible in the description of your instance each time you ssh.
If this happens "from one day", the IP your AWS EC2 instance associated with may be blocked from this day.
If the IP is blocked, you need to add a new dynamic IP and associate this new dynamic IP with your AWS EC2 instance.
Steps:
1.Go to "Elastic IPs".
2.Allocate new address.
3.Choose this new address. Click "Actions" and "Associate address".
4.Select your instance and Click "Associate".
In my case, adding new dynamic IP to my AWS EC2 instance fix the problem.(My problem was I can't access to AWS EC2 instance from one day too)
Kindly create a new security group and select type SSH
SSH
TCP
22
0.0.0.0/0
In addition to Adam's answer, also check if your public subnet's RT table is using the IGW and the private Subnets' RT has 0.0.0.0/0 -> NAT instance Id.
Check that you are connecting to the public dynamic IP or associate an ElasticIP and connect to it.
I was using public wifi in the library and that was not letting me connect, which I came to know when I switched to my mobile hotspot wifi (password protected). Try switching to a protected network.
Even I also faced this same problem, good to know i have not allowed from route table.
Check EC2 Instance associated
And try these steps
subnet,Route table and allowed CIDR blocks
key pair associated with EC2 Instance
security group ssh port 22 allowed or not.
If you are accessing from a new machine, then make sure the IP of the machine you are accessing from is included in the inbound rules. If not add a rule
SSH | TCP | Port:22 | Source: MY IP
For me, I had to delete all my rules for the security group for the particular instance and create new rules for the same ssh, http and https
For some reason after stopping the instance and starting it later, my IP changed... probably because I switched my wifi connectivity device.
But putting new rules with the new IP address worked! You can check the ip by googling "myip"
Well, if this happened all of a sudden, try disconnecting and connecting back to your VPN (if accessing through a VPN). It might work!
I was able to fixed it simply by following this instruction
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html
It sets up your private key pair as well as security group. The issue I think mainly because the default security group doesn't has a ssh inbound for your local IP setup.
If none of the troubleshooting steps above work for you, make sure that your EC2 container meets all system requirements for the application(s) you're running on the container. SSH will sometimes not be able to start if the memory runs out before getting to the SSH service.
Example: I was perfectly able to SSH into my EC2 container when I first launched it. I then proceeded to install Mailcow. My issue with SSH arose after restarting my container because the application I had installed required heavy services -- Docker, for example. After reading the system requirements from Mailcow, I realized a t2.micro wasn't even close to what I needed to run everything. I changed to a t3.large, and all worked perfectly.
Even after doing this for awhile, you can sometimes forget the most basic steps and requirements.
Try stopping the ec2 instance and then restarting. It worked for me!
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.
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.