Yet another tutorial on How to install XFCE and VNC on Debian-based server

edited May 2020 in Technical

I have tried to write in the shortest and most understandable way so as not to waste anyone's time

What is this post for?

This's for everyone who hates the boring terminal. However, It could slow down your server

Install the XFCE desktop environment

It's really easy to install a desktop environment. Before move on, make sure you've updated your server. If not, run following command :

sudo apt-get update

Now, everything's ready. You just need a command

sudo apt-get install xfce4

You may want Xubuntu desktop which included lots of custom applications for a better experience.

sudo apt-get install xubuntu-desktop

Installing VNC Server

I'm familiar with tightvncserver. It works well. So I'll guide you to install it.

sudo apt install tightvncserver

Next, we will initialize VNC Server for the first time:

vncserver

To proceed with configuring VNCserver with XFCE, we need to kill the session on:

vncserver -kill:1

You need to edit xstartup file.

nano ~/.vnc/xstartup

Change file to the following content :

#!/bin /bash
xrdb $HOME/.Xresources
startxfce4 &

Save the file and then restart VNC Server.

vncserver

Congratulations, you made it! Now open your VNC client and enjoy your server!
Please correct me if there're somethings I'm wrong


Comments

  • vncserver -kill: 1

    shoule be changed to

    vncserver -kill :1

    Thanked by (2)quangthang Not_Oles
  • @sonic said:
    vncserver -kill: 1

    shoule be changed to

    vncserver -kill :1

    Thanks for correcting me. @AnthonySmith can you edit my post?

  • InceptionHostingInceptionHosting Hosting ProviderOG

    @quangthang said:

    @sonic said:
    vncserver -kill: 1

    shoule be changed to

    vncserver -kill :1

    Thanks for correcting me. @AnthonySmith can you edit my post?

    done

    Thanked by (3)Ympker Not_Oles quangthang

    https://inceptionhosting.com
    Please do not use the PM system here for Inception Hosting support issues.

  • Not_OlesNot_Oles Hosting ProviderContent Writer

    @quangthang Thanks for your new tutorial on LES!

    I think it is wonderful that you are trying to help other LES users! It also is wonderful that you are practicing your English.

    I am not an expert on remote desktop, and I might be wrong, but:

    I thought that one issue with using a remote graphical environment with TightVNC was that the connection is unencrypted.

    If the connection is unencrypted, then anybody who is listening can get your password plus all other private information passing over the unencrypted connection.

    To secure their remote desktop connection via TightVNC, people sometimes use an ssh tunnel.

    Another way to secure the connection is to connect via Microsoft Remote Desktop Protocol (RDP), instead of TightVNC. RDP is encrypted. So, when you connect via something like Xrdp, my understanding is that you get an encrypted connection.

    To connect safely to the remote desktop, you need (1) TightVNC + an ssh tunnel or (2) RDP or else (3) one of several more secure connection possibilities. People have packaged VNC together with encryption, and maybe there is an open source VNC + encryption package. A knowledgeable friend of mine likes the SPICE protocol.

    Please consider adding to your excellent new tutorial an extra step about an ssh tunnel, Xrdp, or some other method of securing the connection to the remote desktop.

    Folks, please hit me with the clue bat if I am not right. Thanks!

    Thanked by (1)quangthang
  • @Not_Oles said:
    @quangthang Thanks for your new tutorial on LES!

    I think it is wonderful that you are trying to help other LES users! It also is wonderful that you are practicing your English.

    I am not an expert on remote desktop, and I might be wrong, but:

    I thought that one issue with using a remote graphical environment with TightVNC was that the connection is unencrypted.

    If the connection is unencrypted, then anybody who is listening can get your password plus all other private information passing over the unencrypted connection.

    To secure their remote desktop connection via TightVNC, people sometimes use an ssh tunnel.

    Another way to secure the connection is to connect via Microsoft Remote Desktop Protocol (RDP), instead of TightVNC. RDP is encrypted. So, when you connect via something like Xrdp, my understanding is that you get an encrypted connection.

    To connect safely to the remote desktop, you need (1) TightVNC + an ssh tunnel or (2) RDP or else (3) one of several more secure connection possibilities. People have packaged VNC together with encryption, and maybe there is an open source VNC + encryption package. A knowledgeable friend of mine likes the SPICE protocol.

    Please consider adding to your excellent new tutorial an extra step about an ssh tunnel, Xrdp, or some other method of securing the connection to the remote desktop.

    Folks, please hit me with the clue bat if I am not right. Thanks!

    You're right. VNC is insecure. If someone is concerned about security, they should learn about ssh tunnel or some others protocol. I don't have much experience with ssh tunnel :(

  • edited May 2020

    For decades, X on a server has been viewed negatively (poor pun), from a security standpoint. Bearable on an intranet but I, for one, would never consider it for internet use. Not being a security expert, I stayed clear of it. Ah, the days of sysadmsh and curses-based admin menus.
    Graphical interfaces were never seen as required on a *nix server and I've experienced corporate Windoze servers being brought to their knees, purely because of display drivers (too tight an integration between OS and graphics). I need to take the time to investigate this new fangled CentOS 8 admin.
    I'd have thought a VPN/ssh tunnel would be a prerequisite for using X across a WAN. Not sure if wayland is any more secure.
    Just my thoughts on the subject: you may ignore. ;)

    Thanked by (1)quangthang

    It wisnae me! A big boy done it and ran away.
    NVMe2G for life! until death (the end is nigh)

  • Agreed that VNC should not be exposed to the internet. SSH tunnel, VPN (OpenVPN, WireGuard, ipsec, etc), or SSL to a Guacamole server on the LAN. Port tcp/5900+(display number).

    If using TightVNC server, don't forget client must also be tight (rather than real, ultra, etc) in order to use the jpeg encoding. VNC as a protocol is a bit chatty; Xrdp is another option.

    Thanked by (1)quangthang
  • I seem to prefer xrdp over *vnc as it is easier to setup/manage and to connect to (since a vanilla RDP client will do). Performance wise I don't have any detailed comparisons, but from what I remember (initially when I was choosing one over the rest), xrdp seemed to be the best overall.

    So what I wanted is:
    1. Easy setup (or at least a one time clearly manageable headache)
    2. Secure - preferably no public access and tunnel-able via ssh
    3. Separate (independent) of SSH credentials for login
    4. Decent experience - mainly for casual browsing with Firefox/Chrome

    I found xrdp ticked all of the above and so what I did was:

    Setup xrdp and whatever other window session manager I wanted (I went with fluxbox as I needed a basic remote desktop for browsing). I tweaked xrdp to only bind to localhost on port 3389 (so no more public exposure), modified sesman (and related pam settings) to use an independent password file to allow xrdp logins (independent of SSH and main user logins).

    This now allowed me to use SSH to login as user and then connect via a tunnel to localhost:3389 for rdp client access at which point the xsession manager takes over runs fluxbox (or whatever else you choose).

    All sweet and dandy - only public port (or firewalled) is SSH. Restrict SSH auth to pubkey and you have no further security issues.

    Setup a simple SSH tunnel for RDP access and you have a nice sweet browser session (that can be disconnected/resumed at will). With a little bit of creative ssh config tweaking/scripting, the SSH tunnel becomes automatic and will "die" when the RDP session disconnects.

    Depending on your network speeds/latency, the lag will vary but on the whole I really can't complain on this setup.

  • @nullnothere said:
    I seem to prefer xrdp over *vnc as it is easier to setup/manage and to connect to (since a vanilla RDP client will do). Performance wise I don't have any detailed comparisons, but from what I remember (initially when I was choosing one over the rest), xrdp seemed to be the best overall.

    So what I wanted is:
    1. Easy setup (or at least a one time clearly manageable headache)
    2. Secure - preferably no public access and tunnel-able via ssh
    3. Separate (independent) of SSH credentials for login
    4. Decent experience - mainly for casual browsing with Firefox/Chrome

    I found xrdp ticked all of the above and so what I did was:

    Setup xrdp and whatever other window session manager I wanted (I went with fluxbox as I needed a basic remote desktop for browsing). I tweaked xrdp to only bind to localhost on port 3389 (so no more public exposure), modified sesman (and related pam settings) to use an independent password file to allow xrdp logins (independent of SSH and main user logins).

    This now allowed me to use SSH to login as user and then connect via a tunnel to localhost:3389 for rdp client access at which point the xsession manager takes over runs fluxbox (or whatever else you choose).

    All sweet and dandy - only public port (or firewalled) is SSH. Restrict SSH auth to pubkey and you have no further security issues.

    Setup a simple SSH tunnel for RDP access and you have a nice sweet browser session (that can be disconnected/resumed at will). With a little bit of creative ssh config tweaking/scripting, the SSH tunnel becomes automatic and will "die" when the RDP session disconnects.

    Depending on your network speeds/latency, the lag will vary but on the whole I really can't complain on this setup.

    I can totally agree with you. However, Xrdp isn't so easier to setup than VNC.

Sign In or Register to comment.