I am using a Digital Ocean VPS instance running Ubuntu 18.04 and I’m wondering, is it possible to install a GUI desktop interface to the VPS instance? I am currently accessing it via Putty - authenticating to a SSH server.
Also, is it possible to setup the VPS as a proxy for forwarding requests on behalf of say a VM instance running on my home computer? I have a slow internet connection(1 MB/s) and I’m wondering whether that would impede any activity on Burp Suite for Web App testing such that it would be best(if possible) to utilize the VPS service’s fast internet speed. I plan on using Burp Suite Intruder and if it is possible for this workflow to disrupt a company’s service and trigger a security measure that can blacklist my home network, it would be great if I could take advantage of the VPS connection or, again if possible, installing Burp Suite on the VPS instance.
Thank you.
[UPDATE]
So I installed a desktop interface but accessing it remotely presents lots of latency and the mouse pointer on the Ubuntu VPS instance is not synced/aligned with where I’m pointing my mouse. The mouse issue happens even when I change the display settings to another resolution. Not a good result. The session was performed through DigitalOcean’s console access/VNC functionality. Maybe another VNC service would give me better results at least with the mouse pointer issue?
[UPDATE 2] Mouse synced up nicely with TeamViewer remote access program as opposed to Digital Ocean’s VNC function. However the latency is
What you describe is possible, however it’s not going to solve your problem because the connection to where you work is 1 MB/s which will make it almost useless. I guess you have a lot of latency too, so it’s going to be a very unpleasant experience.
What you can try to do is to have different useful tools that replace Burp Intruder in your case, or things like that, but that do not require a GUI. There are many.
Take advantage by installing the control panel scripts like Cpanel (Paid) or VestaCP (Free). It comes with many benefits after all. You will find most option there.
It depends. But I think that relying on your 1MB connection to work will make things slower when using a VPS. However, for things like running Intruder a lot or things like that, it may be useful. In that case, I would have Burp running locally for things like manual testing (Proxy, Repeater) and the VPS for things like Intruder and similar tools that send many requests at the same time.
Anyway, the best way to make sure that it is useful for you, is to try the workflow you have in mind for a few weeks and evaluate if it’s better than your current workflow.
This isn’t really a direct answer to your question, but I would suggest embracing the joy of a text-based workflow since many of the tools you’ll be using are also text-based.
As far as Burp goes, have you tried using it through a SOCKS proxy? You’d do ssh -D 9050 yourname@yourvps.com then configure Burp to proxy traffic through http://localhost:9050.
Instead of installing a GUI on VPS to manage things on the server, opt for a managed DigitalOcean server, such as Cloudways that handles server management operation in a go where the user stays focussed more on his business. You won’t have to install the GUI on VPS by running hectic commands. Cloudways takes care of that on the fly so that user commit more time to the business growth.
Instead of installing a GUI on VPS to manage things on the server, opt for a managed DigitalOcean server such as Cloudways that handles server management operation in a go where the user stays focussed more on his business. You won’t have to install GUI on VPS by running hectic commands. Cloudways takes care of that on the fly so that user commit more time to the business growth.
This would depend on the VPS and what is installed under Ubuntu.
If it’s a server install, it probably has a number of GUI (X) items not installed, since it can have a dramatic impact on how much disk space and CPU cycles are used.
If it does have the workstation version with the default workstation packages, there is a desktop sharing ability using VNC to connect to it.
Alternatively, you can get an X server for your Windows system and ssh in with putty (using X-forwarding enabled) to launch graphical applications to appear locally on your Windows machine while running on the remote system.
Your best bet is to learn how to use the command prompt, though. It will let you run a leaner system, lower CPU usage, and simplify how to connect to your machine (just using SSH instead of a slower graphical interface).
I really like Mackenzie64 last suggestion. My first exposure to Linux years ago was Ubuntu desktop in a VM running on VirtualBox on my laptop. I worked through several methods to install a desktop environment on Ubuntu server on Linode. I was able to connect to them using VNC, but as you have noticed there is lag and slow response. Over time I have gotten familiar with the command-line and enjoy using it. I am still learning new things and there is still more I can learn, but I no longer feel the need for a desktop env when I SSH to a Linux server.
X11 forwarding needs to be enabled on both the client side and the server side.
On the client side, the -X (capital X) option to ssh enables X11 forwarding, and you can make this the default (for all connections or for a specific conection) with ForwardX11 yes in ~/.ssh/config.
On the server side, X11Forwarding yes must specified in /etc/ssh/sshd_config. Note that the default is no forwarding (some distributions turn it on in their default /etc/ssh/sshd_config), and that the user cannot override this setting.
The xauth program must be installed on the server side. If there are any X11 programs there, it's very likely that xauth will be there. In the unlikely case xauth was installed in a nonstandard location, it can be called through ~/.ssh/rc (on the server!).
Note that you do not need to set any environment variables on the server. DISPLAY and XAUTHORITY will automatically be set to their proper values. If you run ssh and DISPLAY is not set, it means ssh is not forwarding the X11 connection.
To confirm that ssh is forwarding X11, check for a line containing Requesting X11 forwarding in the ssh -v -X output. Note that the server won't reply either way, a security precaution of hiding details from potential attackers.
Since you are using PuTTY you are on Windows - so you need to find an X server. Like Hummingbird or the one in WSL or even Cygwin X11.
Turn on compression within ssh as well.
Next…
SSH Socks Proxy
Then wire up your browser to use your localhost SOCKS proxy an it will ride the ssh tunnel.
OR
Use ssh local port forwarding:
ssh -L 9000: localhost:9001 [host]
Putty has a similar config option…
Then you wire your browser to connect to localhost port 9000 and make sure burp on the server is listening on 9001 an you are good to go.
