Of late I've been more and more feeling like some bedroom network hacker in trying to test out some connectivity options to see which performs the best.
In this specific case I just want to scp some files from one server (on premise) to a server in public cloud - in this case Azure but it could be any cloud (or indeed any server actually).
With Azure we can copy stuff to a private address (either via expressroute or some sort of VPN), or to a public address - again via express route or direct internet breakout.
In our case though while both of the above options work the speed is not that great (for whatever unclear reason).
What I wanted to try was having a connection direct from our datacentre location to Azure via the shortest network path possible - the other options (again for whatever reason) go a more convoluted route and we don't get the transfer speeds we would like.
We have a proxy service directly in the datacentre which has a local internet breakout - this in theory should mean that if I can go out through this path then I should have a much quicker connection.
However I can't ssh out through a proxy - that's impossible right? - a standard forward proxy just does http and https?
Well that's initially what I thought too until I did a bit of digging and it seems there is a way. Now I'm not condoning the use of this and I don't really know the provenance of the one tool being used here so be mindful of that but it does work and is actually quite interesting.
So how to set it up?
Well first up you need to install an additional bit of software - in my case I used corkscrew as this seems to be the easiest to work with (there are alternatives available). There are various repo's to get this from - just choose one you trust more than the others :-)
Once you've downloaded the file (in my case corkscrew-2.0-25.fc30.x86_64.rpm) just install that with the rpm package manager - default is into /usr/bin
rpm -i ./corkscrew-2.0-25.fc30.x86_64.rpm
Once that's installed you then need to make some changes to your ssh config to make use of it - to do that do the following:
Under your $HOME/.ssh directory create a file called config (and this is standard ssh usage here - I just didn't realise you could do this sort of thing)
Within that file create some entries that look like this
Host x.x.x..x
Hostname x.x.x.x
ProxyCommand /usr/bin/corkscrew yourproxyserver yourproxyserverport %h %p /home/username/.corkscrew-auth
where x.x.x.x is the public ip address of the server you want to connect to, proxyserver is (you guessed it) your proxy, likewise the proxy port - the final bit being a pointer to a file containing a username:password combination (only required if your proxy requires authentication - otherwise miss out completely)
With the auth file (if you need one) just have the authentication as
username:password
No need to escape special characters or anything in there
And that's kind of all you need to make this work - now if you just do the following
ssh x.x.x.x -l username
when ssh sees x.x.x.x it looks it up in that config file and sees that it has to route the connection through the proxy - and it just works (no seriously it does work just as simply as that....)
The only other issue you might get is that the proxy doesn't like you going to port 22 via this method and may drop the traffic because of that. There is a way round it though - just reconfigure your ssh daemon to listen on a 'friendly' port - so as an example
edit /etc/ssh/sshd_config and replace Port 22 with Port 443 then just restart the sshd daemon
service sshd restart
After that the daemon is running on port 443 - you can then change your scpcommand to this
scp -P 443 /pathtolocalfile remotelinuxuser@publicip:/remotepath
The proxy then sees 443 and thinks everything is fine and lets it through.....
Honestly still feels like hacking though - maybe its occasionally useful but I wouldn't really build anything production based on this kind of thing - in my case the network performance was slower anyway.....
That's an awesome bit of hacking!
ReplyDelete