Intro
At some point you may have to present a quick prototype or perform a test involving a connection between the cloud and an onprem system. This would not be a problem if you have access to a SCC (Cloud connector) connected to the SCP tenant or if you can connect your own SCC to the tenant. However, in some companies, you will have to go through an endless sort of formalities before you can include a new host in the current SCC or your tenant user simply won't have the necessary roles to register a new cloud connector. In this post, I will present a method in which you would be able to connect your SCP tenant to an onprem system without using the SCC (or a reverse proxy). This is by no means intended as a replacement for the SCC or for productive scenarios, on the contrary (and as I've already commented), it is simply an aid to eliminate dependencies when elaborating proposals, prototypes or proof of concepts.
About SSH tunnelling
SSH tunnelling is a method of transporting almost any-type of networking data over an encrypted connection. Through an SSH client, what we want to achieve is to open a port on a remote system (SSH Server) and redirect that network traffic to a predefined local address and port. This mechanism might not work if your company utilises a sophisticated ssh packet hound that blocks tunnelling or if you cannot connect to a remote SSH server from within your local network.
Requirements and set-up
The requirements are straight forward: 1.- an SSH server exposed to the internet and 2.- an SSH client with access to your Local Network and to the SSH server.
Regarding the SSH server, it can be anything: a computer in your home, a linux based router, a container somewhere in the cloud, or a server on a public cloud (AWS, Google, DigitalOcean, etc). For this post, I will be using a Digital Ocean "droplet" as I like their simple pricing model (among other things). You can use my referral code to get credits that would keep your instance running for almost two years, but you should be fine with an AWS EC2/Google CE instance as well (one year free tier most of the time).
Assuming that you have an SSH server available, you will need to check a few things:
- Your ssh service is configured to allow TCP forwarding and gateway ports
- You firewall rules allows you to open some ports
- Your ssh user has the right authorisations
Enabling tunnelling in the SSH server
The first point, can be checked by having a look at the sshd config file. The two required parameters are:
AllowTcpForwarding yes
GatewayPorts yesIn my Debian instance, this file is located at /etc/ssh/sshd_config
Beware that these parameters can be associated to an specific user, port, etc. So look carefully and, should you need to change these parameters, remember to restart the ssh service.
Create firewall rules
In your networking settings, create a firewall rule to let inbound traffic on an specific port to your SSH server. In the Digital Ocean's cockpit, I've created a simple rule to allow inbound connections to ports 9090 (the one that will be forwarded) and the 9922 as a non standard SSH port (that often uses the port 22).
In this example, I am allowing traffic from everywhere. However, for extra security, you could restrict your rule to allow traffic on a granular level (like allowing traffic only from specific IPs). A list of SCPs IP ranges can be found in this link (Link from SAP Note 2418879):
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/350356d1dc314d3199dca15bd2a...
Instantiate the tunnel
Using a computer connected to the local network and that is capable to connect to the SSH server, establish an ssh connection that initiates the port tunnelling. In this example I'll be using OpenSSH and assuming user/password authentication.
ssh -R <PortToOpenAtServer>:<LocalNetworkHost:Port> <sshUser>@<sshServerHost> -p <sshServerPort>Example:
Explanation:
- -R indicates that we will set up a remote port forwarding
- First parameter will be the port to open at the server. In this case 9090
- Second parameter, the target host at our local network and its port, In this example, localhost:8080 (I'll be running an small service on my computer)
- -p indicates the SSH server port (9922), required in this case as we are not using the default port (22)
- I am using a root access and password authentication... I shouldn't 🙂
We can verify that the server is now listening on port 9090, using the same process id that our active SSH connection that is tunnelling the incoming requests:
Testing
Now that the tunnel is active, we are able to test connections from SCP. To simplify the test, I'm just running a simple nodejs program on my local machine. From a web browser, I can verify that the tunnel is on.
In SCP, I've create a new destination, please note that the Proxy type is "Internet" as we are not using the cloud connector this time. After saving and testing the destination, I get a nice HTTP 200 code confirming that SCP can reach my local machine.
In this scenario I've exposed my local machine, but it can be any other local resource, such as an ECC/S4 installation, SAP PO, etc. I've tested this approach using the WebUi and CPI, even under VPN connections without problems.
Final words
An SSH tunnel is a solid and powerful tool, but "With great power comes great responsibility". SSH tunnels are secure by nature, but misutilisation and loosely managed systems could leave you with nasty backdoors and a punched firewall. Hence, keep the this approach to a minimum, specially if you are not very familiar with them and of course use the Cloud Connector when possible. Finally, make sure you're not breaking any of the company's security policies with this method.
- SAP Managed Tags:
